Library rewrite

[stifskere]

Pre-submission Checklist

• I've checked existing issues and pull requests
• I've read the Code of Conduct
• I've implemented tests for my changes
• I've listed all my changes in the Changes section

Changes

This rewrite comes with the translation contexts along with a change in the tree.

• The translation tree now has scoped errors, macros panic only on accessing these parts.
• Dynamic loading is now allowed, you can use translatable programmatically, not only in your project.
• The PR also refactors the repository workflows and rewrites metadata and related files.

Large PR warning

While learning Git, I mistakenly merged two unrelated histories, which caused lost commits in the history and resulted in a large, confusing diff commit. The actual code changes remain intact, but the commit history is compromised.

To avoid this issue going forward, I’m enforcing a linear history policy using rebase instead of merge, which should keep the commit log clean.

This PR is foundational and may be confusing. Future work will be done via smaller follow-up PRs that will reference this one.

This rewrite includes breaking changes and will bump the version to 2.0 upon merging.

I apologize for any inconvenience caused by this process.

Follow-up

From now on, I will create other PRs to merge and list them here (#32). The follow-up work will continue through those.

Todo

• Rewrite the error system, Now the error system breaks all the translations and adds errors to all translation! invocations, even if they are not related, The parsing system for translations should be refactored in order to make errors non-breaking, see [FEATURE] Improve error system prior 2.0 #24.

• Source constructor, The macro system should work over a source constructor, and that should also be exposed as a public API, this should integrate Bon to make the constructors compile-time checked.

• Add runtime metadata, For manual constructors the comments over translations should be able to be retrieved, along what translations are available, if there is a fallback available for that translation and where it may be found.

• Macro rewrite, The macro crate should be written to work with the existing parsing components, there should be a translation! macro taking the usual arguments, except now we should explicit between static and dynamic for all the arguments except the template fills and another macro for contexts as structs, these load translations and should be serializable.

• Add fallback translation support, There should be a configurable fallback for missing translations, Whether the macros compile error or return an option should be configurable from Translatable.toml. The fallbacks should also be available for the public source constructor API. see [FEATURE] Implement static fallback languages #21.

• Public API Cleanup, The public API should only expose the macros useful to the user, and should also have a prelude to include everything there is in the crate, namespace agnostic. The other crates should have documented in them that they are not for public use alone.