Publish to crates.io

[Bromeon]

As soon as the library becomes a bit more stable, we can release our first 0.x versions to crates.io.

Crate publishing was in the past blocked by unreleased dependencies, see PoignardAzur/venial#32. Should be good now.

The codegen approach from "output directly in dependent crate" needs to be modified, so that all files are output in the own crate.

[Bromeon]

My current plan for crates.io release with multiple Godot versions:

1. We have a dedicated crate that stores prebuilt Godot artifacts like extension_api.json or gdextension_interface.h.

   • Such a crate would track Godot 4.x-stable releases with its own version scheme.
   • Since GDExtension API is released only in minor versions, we would only have a release for 4.3, but not on 4.3.1.
   • If there are important bugfixes in the GDExtension API (not implementation) and the above turns out not to be enough, we may also include patch releases like 4.3.1.

2. The main crate godot by default depends on the latest Godot release.

   • Raising the Godot API level requires a semver bump.

3. To support older Godot versions, you can opt in to a respective GDExtension API level via Cargo features.

   • godot = { version = "...", features = ["api-4-1"] }
   • These are mutually exclusive.
   • One day, Rust may implement this properly, but we have to use what we have today.
   • mlua uses a similar approach with lua51, lua52, lua53, lua54 features.

4. To support custom versions (e.g. locally built ones), we can also use a feature.

   • godot = { version = "...", features = ["api-custom"] }
   • This cannot be used together with other api-* features.

This also means that if two crates a and b depend on the same version godot 0.5, they will by default get the same Godot API level (let's say 4.3). If a now specifies an api-4-1 feature, this will override the choice of b, too. This either works out of the box, because b only uses features that are already available in 4.1 (or polyfilled). Or, it fails to compile if 4.2 or 4.3 exclusive features are used.

An alternative approach would be to always require explicit API level. This may be more explicit, but for dependents that don't care about the API level, it makes things less flexible: if b specified api-4-3, it would be categorically incompatible with a's api-4-1 -- even though GDExtension may permit this. So I'd probably try the above approach first.

Yet another idea would be to take the minimum of any specified API level. If one crate specifies api-4-1 and another api-4-2, then API level 4.1 is selected. This bears the risk that features only introduced in 4.2 are unavailable, thus failing compilation -- but at least coexisting api-4-1 and api-4-2 would not always fail. However, this minimum logic may be hard/impossible to implement with the Cargo dependency system, as we can't simply depend on one prebuilt version.