expose create-native-mints in node-litesvm

[jshiohaha]

Description

Expose the ability to create native mints for both SPL token programs to node-litesvm

Motivation

Consumers of node-litesvm have to create native mints on their own. It would be convenient to expose a function to allow for this within the core library.

If accepted, this change makes it as easy as 🔽 (as long as the expected token programs are loaded)

const svm = new LiteSVM()
    .withDefaultPrograms()
    .withNativeMints();

Note: I left the token-2022 feature flag alone since that will dictate what SPL token program is used in the rust token crate

Alternatives considered

Leave the token crate alone, and copy the existing create_native_mint function into node-litesvm. In many ways, I think this is a simpler approach because it (1) leaves token crate untouched, (2) avoids staking token crate as a dependency, (3) easily exposes create native mint functions for both token programs. I think the main downside is that we'd copy some code from the token crate.

Testing

I added a new test token.test.ts to verify the native mint accounts are created as expected

[jshiohaha]

ok @kevinheavey i updated the PR with a different approach that results in fewer changes overall. specifically, i no longer touch or pull in token-litesvm, which reduces the change surface area. let me know what you think - would be great to either merge or close these proposed changes 🙂

i ran into some issues (example) with the stable - xxx-apple-darwin and stable - xxx-unknown-linux-musl builds and made some changes in .github/workflows/node-build.yml, but maybe you know a better way to handle

[Aursen]

I'll fix the CI issues in this PR. However, I'm not entirely convinced that exposing create-native-mints directly in the Node.js API is the best long-term design choice

[jshiohaha]

My main motivation for the change was that I found it annoying to have to re-add the create native mint logic when I used the JS library in different test suites.

Feel free to close this PR if you don't agree with the implementation though. You definitely have more context.