Staked collateral

[jgur-psyops]

• Adds a large number of Anchor tests in TS (e2e coverage now up to deposit/borrow).
• Adds a Bankrun instance to the TS test suite.
• Adds the ability to use SOL assets staked to vanilla Solana staking (https://github.com/anza-xyz/agave/tree/master/sdk/program/src/stake) as collateral to borrow SOL.
• Validators (or anyone: the process is permissionless) will use the Single Pool program (https://github.com/solana-labs/solana-program-library/tree/master/single-pool) to create an "LST" that uses that just that validator (unlike a traditional LST which will have several validators). After a bank for this LST is created, the LST can be deposited as collateral in the main pool. Only SOL can be borrowed against this kind of asset.
• Adds Bankrun simulation of creating a validator, native SOL staking + delegation from users, deposit into a Single Pool, and integration with mrgnlend

Running the test suite:
anchor build -p marginfi -- --no-default-features (repeat for other programs as needed)
anchor test --skip-build

Extras:

• Permissionless ix to create LST banks in an existing group
• Per-group global settings account that controls the config for all staked collateral banks under that group (see init_staked_settings, edit_staked_settings, and propagate_staked_settings)
• Pricing of LST to include appreciation (uses lst mint supply and stake's sol pool balance)

Notes for launch:

• Deploy the single-pool program to mainnet
• Update api/FE for the new asset_tag field in bank.config
• Prepare infra to init, edit, and propagate staked collateral settings for groups
• Update the existing SOL bank's asset_tag to ASSET_TAG_SOL
• Accounts made on the SOL bank prior to this update will use ASSET_TAG_DEFAULT instead of ASSET_TAG_SOL, so they will not be able to be used with STAKED accounts. However, this is probably a good thing: we want users to make a new account for this feature.

[jkbpvsc]

Is the idea here that we don't have to pass 2 extra accounts when configuring a stake collateral bank?
Also the oracle setup should be validated only when the oracle is update which shouldn't happen unless we expect the underlying pyth oracle to change?
I would maybe think that saving on code complexity (additional code) is worth more than saving 2 extra accounts when calling an admin instruction

[jgur-psyops]

Yes, it's for config. The underlying pyth oracle can still update, so we still want to validate it, but the stake mint and pool accounts cannot update after bank inception, so checking them is not necessary after initial add pool.

We could recycle the existing validate_oracle_setup if you prefer but I thought splitting it was cleaner, having it branch within the function will be a slightly larger code change.

[jgur-psyops]

Consolidated validation into one large function