feat: incentives update

[MinisculeTarantula]

Motivation:

This is a draft PR outlining possible incentives-related changes for a significant incentives system revamp.
There are two main goals with the chosen direction:

1. Build a more flexible Incentives system
2. Maximally decouple changes to Programmatic Incentives from other software releases, to accelerate and unblock development of future incentives features

The first iteration of Programmatic Incentives achieved a few goals. It is extremely simple, with essentially no governance overhead, while incentivizing staking in and acting as an Operator within EigenLayer.
However, it is maximally inflexible, necessitating action on the level of a smart contract upgrade (or at minimum, new deployment and multisig + timelock actions) to make any modifications. The next iteration of Programmatic Incentives aims to insert flexibility in the appropriate places. In particular:

• Smaller or more routine changes should necessitate only straightforward on-chain operations. As examples, this could include modifying the split going to different incentives substreams, or changing the rate at which a particular token is being incentivized relative to other tokens.
• Introducing new “incentives types” should necessitate only a sidecar release at worst. As an example, this could include introducing a new incentive type to target Unique Stake specifically.
• Smart contract upgrades – particularly to high-value contracts like the RewardsCoordinator and the EIGEN token itself – should be used as a last resort.

This PR is somewhat of a thought exercise / for illustrative purposes, and not necessarily intended to be an end-product.
At the time of being opened (March 5, 2025) it lacks all testing and contains notable TODOs.

Modifications:

We introduce a governed and fairly flexible on-chain structure for managing changes to incentives which involve solely shifting the balance of incentives distributions, i.e. for driving additional or fewer incentives toward specific staked tokens or towards a specific substream of incentives (which is distributed according to existing programmatic logic).

Additionally, minor, flexible interface and logic changes are made to RewardsCoordinator, to enable medium-complexity changes which introduce new types of incentives distribution logic to be accomplished primarily via a minor Sidecar release, and no longer necessitate a core smart contract upgrade. As part of this update, the Sidecar will need to index and process new events emitted by the RewardsCoorindator.

The primary new contract is the ProgrammaticIncentivesConfig, which will allow the Incentives Council to:

1. Define inflationary substreams, which will each be directed at a specific address, and accumulate a fraction of the total rate of inflation over time
2. Whitelist / blacklist AVSs from the PI system
3. Whitelist / blacklist AVS rewards tokens from the PI system
4. Create and modify vectors used to define how tokens (technically, token Strategies) are weighted against one-another.

Result:

This proposes a serious overhaul to the PI system. See above for more details :)