Migrate repo to a Cargo workspace

[emwalker]

This PR migrates the gosub-engine repo to a Cargo workspace. Discussion thread here.

The idea is that we start out without changing much. The first crate is the gosub-bindings crate, and it goes under a new crates/ directory. Gradually, as we add more code and split other stuff off into their own crates, they'll also go under crates/. Eventually we might end up with a setup like Bevy's.

[jaytaph]

This will be fun rebasing ;-)

Would it make sense though to have certain other components in the engine (dns, config store) in separate crates as well, or should we keep them as-is for now until they outgrow the engine?

[emwalker]

@jaytaph I think the PR will be a lot less ambitious when I move it out of draft.

Eventually I think it makes sense to split out components into separate crates (still in this repo, though). But there's no hurry to do that. We should probably wait until there's a need that prompts it in each case rather than doing it preemptively.

[emwalker]

We need the --all flag now to pick up gosub-bindings. So perhaps good to use make build now.

[Sharktheone]

Maybe you could add a target to build only one specific. But it might make sense to do this as a seperate PR

[emwalker]

While we're here, let's add two more binaries to the CI run.

[Sharktheone]

Maybe you could add a target to build only one specific. But it might make sense to do this as a seperate PR

[emwalker]

Maybe you could add a target to build only one specific. But it might make sense to do this as a seperate PR

Personally, I think keeping crate build --all follows the principle of least surprise, since without it you could end up breaking the crates under crates/ with a code change without knowing it, until someone attempts to build a specific crate you accidentally broke.

Running cargo test --all probably mitigates this situation almost entirely, since I think a debug build happens in the process. I'm not attached to what is in this PR, so feel free to change it in a later PR if it will save a lot on the build time.

[Kiyoshika]

LGTM

[Sharktheone]

Personally, I think keeping crate build --all follows the principle of least surprise, since without it you could end up breaking the crates under crates/ with a code change without knowing it, until someone attempts to build a specific crate you accidentally broke.

Running cargo test --all probably mitigates this situation almost entirely, since I think a debug build happens in the process. I'm not attached to what is in this PR, so feel free to change it in a later PR if it will save a lot on the build time.

I see what you mean. It could reduce the compile time when you have multiple changes. Mostly you only need to build one target. I mean, when you want to test the engine itself, you mostly don't need to build the bindings. When you have changes in other crates, for example when we have a dns crate, cargo also builds this because it has changes. In fact, you can't even compile the crate as a executable because it's a library crate.