Make a separate API crate

[kevinheavey]

I've been meaning to demonstrate what it looks like to have separate crates for a Solana program and its API, and the Ore code is really clean so I chose Ore. Up to you if you wanna merge obviously (if not I'll point people to my fork as a demo), but if you do merge you get the following benefits:

• People who want to interact with the Ore program don't need to compile the whole Ore program
• The API and the program can have different version numbers, so semver works better
• If the program processor has heavy dependencies in the future, the API will be able to avoid those deps and the ensuing dependency hell for users of the crate

What this PR does:

• Makes a workspace and moves the program into the workspace
• Creates a new ore-api crate in the workspace and moves a bunch of code from the program crate to the api crate
• Updates the program code to import the required code from the API

Btw if you want to regenerate the shank IDL, the command is now shank idl -r crates/api

[HardhatChad]

I like the intent. Would it be cleaner to do this by keeping a single crate and using a feature flag instead?

[kevinheavey]

No, if anything feature flags are overused in the Rust ecosystem. I've been meaning to write a piece about this, but here are some problems with that approach:

• If we have N crates (some of which may depend on each other), the compiler can do its best to build crates in parallel. If we have one crate that is spiritually N crates separated by feature flags, the compiler doesn't understand this and can't parallelise the build so well (parallelisation works well with multiple small crates, and works poorly with one large crate)
• It's easy to break something for some combination of feature flags and not notice it. And if you want to be thorough and catch this in CI, you need to check the power set of all your features.
• Separate crates gives you the option of having independent versioning for each of them, which means users of these crates see fewer "fake" version bumps.
• From the user's POV, feature flags could be doing anything like changing the business logic inside a function. By contrast splitting up crates is easier for the user to reason about because crates can't have weird interactions with each other like features can

Sometimes feature flags are kinda unavoidable, like if you want to optionally derive(Serialize) on a struct. That's not something you can achieve with crate splitting, but it's also not something that affects this PR.

[HardhatChad]

Implemented this pattern for the new v2 build. Closing this now