Add `signer-key` to `*-increase` pox events

[zone117x]

The signer-key has effectively become the “primary key” for all signer data. So if I’m trying to lookup information about stackers based on signer-key, it gets pretty difficult when important events like stack-increase and associated events don’t include it.

Based on discussion with @kantai, it doesn't sound possible to add a map that could be used to lookup the signer-key during synthetic event generation for these functions. Another approach would be to just add the signer key and signature args to the functions. It sounds like this might be a good idea to do anyway -- from Aaron:

functions like stack-increase do not take a signing key argument because they are updating an existing entry.
maybe they should, because I could certainly see an argument that those functions actually also need signer-key authorization.
like, imagine a signer authorizes a stacker to use their signing key to stack 100 STX, and then later on that stacker invokes stacks-increase to increase from 100 STX to 10000 STX.

[hstove]

After looking at stack-increase, during part of the function it iterates over reward-cycle-pox-address-list, which includes signer-key in each entry. So it's possible to do the same thing when making synthetic events, but it would need to return a list of signer keys (one for each updated cycle).

[hstove]

Linking discussion: #4424

[setzeus]

Discussing w/ ClarityWG it seems like the best / most practical solution here is to limit 'stack-increase' to users that are not straddling two signer-keys between upcoming cycles (aka they did not 'stack-extend' recently).

That way every check is straight-forward with every iteration just checking that the existing signer-key is equal to the signer-key in the param.

[hstove]

Yep, I think that's the right approach and aligns with @kantai 's comments on expected behavior