refactor: stake withdraw logic

[jstarry]

Problem

The stake withdraw logic is hard to follow

Summary of Changes

No functional changes or error variants should change as a result of this change.

• eccb68d straightforward logical refactor
• cebea2f pull out full withdrawal special case and check it first. Note that if lamports == stake_account.get_lamports(), then it's impossible for checked_add(lamports, reserve)? to fail
• 84a5994 straightforward logical refactor

Fixes #

[mergify]

The Firedancer team maintains a line-for-line reimplementation of the
native programs, and until native programs are moved to BPF, those
implementations must exactly match their Agave counterparts.
If this PR represents a change to a native program implementation (not
tests), please include a reviewer from the Firedancer team. And please
keep refactors to a minimum.

[jstarry]

@lheeger-jump can someone from your team review this change please? It's not that important to merge if you feel strongly against it but this refactoring makes the behavior and error cases for stake withdraws a lot clearer.

[jstarry]

Note that if lamports == stake_account.get_lamports(), then it's impossible for checked_add(lamports, reserve)? to fail

And to elaborate on the above note from the PR description. The reason this is impossible is because it's not possible in the SVM to even temporarily give an account near u64::MAX lamports because the runtime does lamport accounting checks before and after every instruction boundary which prohibit creating lamports out of thin air.