[VS Incentives]: Update AllocateAcrossGauges to support volume splitting

[AlpinYukseloglu]

Background

The purpose of the AllocateAcrossGauges function is to iterate through all active group gauges and execute a distribution to their internal gauges based on their respective splitting policies. This function still needs to be updated (and likely mostly reimplemented) to work with volume splitting/arbitrary splitting policies. A detailed breakdown of the flow of the function is outlined below and in TODO comments in #6366.

Note that the majority of the complexity relating to splitting policies is abstracted into syncGroupGaugeWeights which is implemented in #6366. This function should be able to abstractly deal only with gauge weights without having to deal with splitting policies beyond an initial call to syncGroupGaugeWeights.

Suggested Design

Note: The TODO comments in the function in #6366 should roughly cover the below flow, but since the logic there was implemented prior to the syncGroupGaugeWeights abstraction, it is okay to strip down/delete existing code in favor of a cleaner implementation

The AllocateAcrossGauges function should have the following rough flow:

1. Get all group gauges in state and run the following logic for each
2. Sync the internal weights for the group gauge based on splitting policy (this should just be a call to syncGroupGaugeWeights
3. Calculate the amount to distribute in total (if perpetual gauge then remaining coins, if not then remaining coins / num epochs)
4. Loop through each internal gauge record and distribute pro-rata share using AddToGaugeRewardsFromGauge, which will need to be cleaned up and tested (note that total weight is a group gauge field, so each loop iteration's pro rata share should be currentRecordWeight / totalWeight)
5. Run updateGaugePostDistribute on group gauge afterwards to ensure distribution is tracked in the group gauge
6. Repeat for next group gauge

Testing Strategy

Since this function will likely need to be implemented before or concurrently with group gauge creation logic, testing it could be slightly more difficult. If we want testing this to not be blocked on finishing CreateGroupGauge, we can take a similar approach to testing as was done in #6366 (with some tweaks) and do the following flow:

1. Create pools to split across, triggering their internal gauges to be created as well
2. Use a valid group gauge object(s) as test field and set it/them in state using types.KeyPrefix(types.GroupGaugePrefix) as key
3. Run function

Since no actual balance transfer is made (funds just stay in module account), this approach should not cause any major issues and would likely be the appropriate approach to test more custom/granular scenarios even if group gauge creation logic was already complete.

Acceptance Criteria

• All new and existing tests pass
• Remove test skips and related TODOs in x/incentives/keeper/distribute_test.go