[Bug] Incorrect build of `move-native` for `move-mv-llvm-compiler` (wrong `target_defs`).

[nvjle]

🐛 Bug

We would like to reference values from move_native::target_defs, such as
ACCOUNT_ADDRESS_LENGTH, but we seem to be getting the wrong
target_defs compiled in on move-mv-llvm-compiler for Solana.

Unfortunately, it does not seem possible currently to get the correct Solana target
definitions because move-native is built two different ways. For the runtime scenario,
it is built correctly with the "solana" feature by the platform tools and therefore gets
the proper target_defs (e.g., account address length).

On the other hand, when it is built for move-mv-llvm-compiler, it uses the Move-blessed
Rust version. That would ordinarily be fine except that we can't enable feature "solana"
with that toolchain (and recall, we need feature "solana" to get the proper target_defs
compiled in). The move-native crate is no_std, and interferes with std on the compiler
build (e.g,, duplicate panic_impl). Also, in the "solana" config, the crate requires
feature(default_alloc_error_handler) which is rejected by the Move-blessed Rust.

As near as I can tell, it's a catch-22 and will require a bit of refactoring in move-native or
some other way of building for Solana target definitions.

As a result, we're having to hardcode, e.g., 32 in the compiler rather than using the symbolic
target definition ACCOUNT_ADDRESS_LENGTH (want to be target agnostic ideally). That
symbol currently returns 16 for some other target chain.