token-2022: Add Reallocate instruction

[CriesofCarrots]

Some extensions are opt-in for token account owners at any time after the account has been initialized. In these cases, the owner needs the ability to reallocate their token account data to be large enough to hold the new extension. Previous approaches attempted to do this in the initialization logic of the specific extension, but borrows on the token account were messy, and it was inefficient to include additional reallocation-specific accounts (payer and system-program) on every initialization.

This PR adds a separate Reallocate instruction to handle the data resize and rent-exempt-reserve funding for a provided set of extensions.

First and last commits can be ignored for the purposes of discussion

[joncinque]

I really like this! It looks good to me, but I'll let Michael give the final 👍 since Confidentials need this most. Just the one nit on that unpack_after_realloc

Pull request has been modified.

[joncinque]

Looks good, just the one bit on set_account_type that we may want to consider if we ever use set_account_type before doing a check earlier.

[joncinque]

Since we only need to consider this for accounts at the moment, we don't need to worry about this case, but I want to get it out there.

In a vacuum, if you pass in a buffer that currently contains just a base mint and call this with S = Account, it will succeed, correct? type_and_tlv_indices only checks for the opposite case of passing in a buffer containing a base Account but call it with S = Mint. I wonder if just to be totally totally safe, this should check the is_initialized byte to make sure it's actually an Account if S = Account. Doesn't make it too generic though...

Probably doesn't need to get done here, and probably won't become an issue, but this exact case has been in the back of my mind for awhile now.

[CriesofCarrots]

Mm, yeah good point. I originally had let base = S::unpack(base_data)?; in there, which would protected against that, but deleted for expense reasons. I'm going to merge this as-is, but will file an issue for us to fix in a follow-up.