Extract reserved-account-keys crate

[kevinheavey]

Problem

• solana_sdk::reserved_account_keys blocks moving out solana_sdk::transaction
• It would be good to be able to use important program IDs without importing heavy dependencies or inlining them

Summary of Changes

• Extract reserved-account-keys-crate and re-export for backwards compatibility
• For every ID definition imported by reserved-account-keys, move that definition to reserved-account-keys and re-export it where it used to be
• Make std optional in the new crate. When no features are enabled, the new crate is just a bunch of ID definitions and it compiles very quickly, so there is no noticeable difference in compile time to any crate that pulls its own ID definition from reserved-account-keys

This branches off #3140 so that needs to be merged first

[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.

[kevinheavey]

This might be cleaner as two separate crates? One that just contains the ID declarations (perhaps solana-sdk-ids) and another containing ReservedAccountKeys &co.

This would avoid having to do all the feature and target_os stuff that ended up being uglier than I expected.

@joncinque thoughts?

[kevinheavey]

This might be cleaner as two separate crates? One that just contains the ID declarations (perhaps solana-sdk-ids

I see there is already a deprecated solana_program::sdk_ids module so the name would clash. But no other name comes to mind and it wouldn't be the worst thing to clash with