Runtime: WGs - manual push salary to workers _or_ reducing the payment intervals

# Problem
As mainnet has evolved it appears that paying workers with the fluctuating exchange rate has become a bit annoying. WG leads must time their payments and do some annoying calculations to make sure things line up properly. It is likely the impact of this will be somewhat lessened when we move to the new one month council duration but it is still a "papercut" that adds a certain amount of friction to the WG leads workflow.
* This forum thread provides some context from DAO participants on the difficulties faced with the current system: https://pioneerapp.xyz/#/forum/thread/749
* I think the theory with the current system was that workers would have a relatively stable payment that would only change periodically. It is really difficult to anticipate how much the price of the token may fluctuate in the future. In the event of dramatic price fluctuations it is possible in the current system for workers to be vastly overpaid (although this is somewhat mitigated by the current usage of the EMA30 pricing metric)
* Leads must currently rely on the CLI which is not very straightforward to use and given the requirement for various manual calculations is prone to human error. This reliance on the CLI is not a great long term strategy as it limits the pool of candidates for WG lead positions to only people with very high technical skills.
* Socially, WG budgets are done in coordination with the council only once per term, which means there are few circumstances when a worker's salary is adjusted in the middle of a council term--although this may happen as a sanction against underperforming workers. The only other instance where something similar may happen is when a new worker is hired mid-term, but that doesn't involve the same difficulty.
* The current payment interval is about 1 day, which means after the start of a council term it takes about 2-3 days for budgets to be agreed upon. To also factor into this, there are sometimes weekends and public holidays that delay things. This means it is annoying for a lead currently to try and perfectly time worker payment adjustments.
* Some leads are doing partial payouts to workers via the `spendFromBudget` (discretionary spending) extrinsic in order to deal with this. This causes a great deal of annoyance because unlike the `rewardPaid` event that is tied to a worker ID, the `spendFromBudget` extrinsic is not tied to a worker ID

# Solution 1 - manual push payments to workers
* Allow the lead to toggle workers between auto payments and a manual push payment type that they can do once per term
* _or_ remove automated payment events entirely and change to a completely manual push payment system
# Solution 2 - adjust discretionary spending extrinsic
* Add a `workerId` field to discretionary payment extrinsic or add a new extrinsic entirely that triggers a `rewardPaid` event
# Solution 3 - reduce the payment interval
* It seems extremely unlikely that we will ever move to something less than a 1 week council period duration. The current worker salary payment interval is only ~24 hours which makes timing of things really difficult. If the timing were something like once per week it would allow a lot more time at the beginning of a council term to adjust things.
* This adds some complexity of aligning with the duration of the council term (especially if an election fails or something like that)
# Solution 4 - Heaving invest in a worker salary tool within Pioneer
* It seems like this may be quite a strong option. If this tool were simple enough to use, and could account for how much a worker has already been paid in the current council term and then adjust the rest of the rewards it could work quite well. If done properly it may just become completely trivial enough for a lead to put in a few numbers and adjust the payments to a worker once per term.
# Solution 5 - Greatly improve the CLI
* I am not personally a fan of this one and I think the resources would be better spent on implementing worker reward adjustments within Pioneer itself as there are a lot more long term benefits.