Token transfer_checked wrapper

[barelooksrare]

This adds a transfer_checked wrapper to the token CPI feature.

Even though the validation functionality of transfer_checked is trivial to implement in Anchor using constraints and checks, there may be cases where using transfer_checked could be preferable and less verbose, while equally safe.

Furthermore, standard transfer is Deprecated in Token-2022.

[Henry-E]

Looks good!

I read up on the transfer_checked function and I still don't quite understand why they exposed an argument that just acts as a double check for the caller. Knowing the mint decimals is redundant since unless the two accounts are the same mint the transfer can't happen anyway. Realistically you can just look at the mint decimal account and check the number of decimals, but maybe they're using a lookup table or something with a list of the most common SPL token types as they did mention it was added to give better support to hardware wallets. Even still that seems like bad practice? So yeh, i'm curious what other motivations there might be for passing in the decimals as an argument to the transfer function? Like when/why would your transfer tokens logic lose track of what token mint it's even using and have to "guess" what the mint decimals are based on some other source of knowledge that isn't mint.decimals?

Also token-2022 is a whole other program. Currently existing SPL tokens won't be able to be used with it, they'll have to migrate over. Eventually there'll be a whole bunch of mints and token accounts associated with different token program.

[barelooksrare]

@Henry-E Yeah I am not sure exactly what purpose it serves to pass in the decimals (perhaps offline signing is the main argument). I'm aware that Token-2022 is a whole other program, but it has the same instruction layout, so one can technically write a single program that works with both standard SPL-tokens and Token-2022 interchangeably