Migrate builtin

[buffalojoec]

As a result of SIMD 0088, we're going to need a migration path for migrating
built-in (native) programs to BPF.

This PR introduces such a migration path, with a series of checks for each type
of program, as well as the accompanying test coverage.

The addition of the migrate_builtin module is comprised of the following
changes, broken down by commit:

• bpf-loader-upgradeable: export get_program_data_address helper: Exports a
  helper from the BPF Upgradeable Loader crate to derive a program's "program
  data address" - something we were previously doing manually with
  Pubkey::find_program_address(..).
• bank: refactor builtins to support disable feature IDs: Here I've refactored
  the BuiltinPrototype struct as well as the static BUILTINS list in the
  runtime to include two Option<Pubkey> fields for feature IDs. Previously, we
  were only tracking feature_id to manage built-in program activations.
  However, with this change, we now track activations and deactivations. I've
  also updated any relevant code in the runtime - two spots in the bank and
  one in snapshot_minimizer - where we use the BUILTINS list. On epoch
  rollover, the bank now checks enable_feature_id to decide when to add
  built-in programs, and checks disable_feature_id to decide when not to
  include built-in programs. This ensures that once a program is migrated, the
  bank won't overwrite it as a built-in immediately after.
  Note: The feature ID for a migration must also be added to BUILTINS. See
  the comment I've added to the functions later.
• bank: add Builtin enum for setting up migrations: This change simply adds an
  enum to builtins.rs to allow for some extra verbosity when choosing which
  built-in to migrate, which will make more sense later.
• bank: init migrate_builtin module: Simply creating the module where the
  migration path will live.
• bank: migrate_builtin: add builtin migration configs: Introducing a struct
  for built-in programs used to load the built-in program and perform the
  necessary checks on its program account to ensure it's ready for migration.
  Unit tests included.
• bank: migrate_builtin: add bpf migration configs: Similar to the previous
  commit, but for BPF (non-upgradeable) programs. All checks performed are
  fleshed out in the tests and described in the comments.
• bank: migrate_builtin: add bpf upgradeable migration configs: Again, similar
  to the previous commit, but this time for upgradeable BPF programs as the
  source program. These checks include checks on the program's data account as
  well.
• bank: migrate_builtin: add bpf migration function: Tying it all together,
  this change adds the actual function engineers will use to migrate a built-in
  program to BPF (non-upgradeable). It leverages the structs that have been set
  up to ensure both the target built-in program and the source program are
  properly configured. All checks must pass before a migration is attempted.
  I've also added tests to the bank's main tests.rs file for this migration.
• bank: migrate_builtin: add bpf upgradeable migration function: Similar to
  the previous commit but for upgradeable BPF programs. One notable difference
  here is the manual serialization of the new program account's pointer to its
  data account. Otherwise, everything mirrors the previous commit, but for
  upgradeable BPF source programs.