Follow-up to commit f31f4201

This reverts commit 3ee0efbd. It works
in the main branch, it works in separate branches when starting
workflows manually, but it doesn't work when a CI run is started with a
merge request.

This was a regression following the move to the edition 2021.
The CallbackUserData was not capture in the lamda, its member were moved.
So the destructor was called right after it was set.
We must make sure we capture the whole CallbackUserData, so put the callback
inside of it. This also reduce a bit of code duplication at the same time.

Test the callback invokation with statefull lambda

We want to be able to put existing functionality behind a feature flag while keeping
the semver compatibility.
This is only possible if that new feature flag is enabled by default, but this is not
working if the users have done `default-features = false` in their Cargo.toml.
So we add new `compat-x-y-z` feature that is mandatory to have and which is
enforced with a `compile_error!`

Now, users that whishes to not have the default features must enable it explicitly.
Say we want only x11 but not qt and wayland, the user will do
```toml
sixtyfps = { version = "0.2", default-features = false, features = ["x11", "compat-0-2-0"] }
```

Now, imagine that in the version 0.2.3, we put the SVG support behind a feature flag.
we will do this in out Cargo.toml:

```toml
[features]
default = ["compat-0-2-0", "x11", "wayland"]
compat-0-2-0 = ["compat-0-2-3", "svg"]
compat-0-2-3 = []

svg = [...]
...
```

That way, the svg feature will be enabled by default for all the users who used previous version
of SixtyFPS, and people that want to disable "svg" can just change from compat-0-2-0 to
compat-0-2-3 in their Cargo.toml

git can create Cargo.toml.orig if there was a conflict. That file might then prevent
the compilation as it contains merge conflict and this crate cannot parse it.

So only use the .orig if the Cargo.toml file don't contains docs comments

Remove the duplicated definition of the IntSize struct and instead
generate it via cbindgen into the public API.

Move "internal" crates into the `internal` directory. This first batch
includes most of sixtyfps_runtime but leaves the rendering backends
alone for now.

pre-commit applied some cleanups to the moved files:
 - Consistent newline at end of file policy
 - trimming trailing whitespace
 - Formatting Cargo.toml files.

 - ModelRc::new constructs a ModelRc from a impl Model
 - ModelRc::form constructs a ModelRc from a `Rc<dyn Model>` or `Rc<impl Model>`

This helps detect call sites. One of them is in the timer doctests though, which we flag as no_run
as a consequence.

Due to run_event_loop() not being in corelib, we can't link to it. Fall back to a
HTML link.

Remove version for dev-dependency in order to be able to publish to crates.io

Co-authored-by: Olivier Goffart <ogoffart@sixtyfps.io>

Bite the bullet and introduce the public API and testing backend as
dev-dependencies, so that we can properly at least compile-test the
doctests, some of which were previously in the public API crate and
require the compiler macro.

This allows re-use of these types from node and the interpreter without
depending on the public Rust API crate, which is a heavy dependency.

Move it from corelib::window::api to corelib::api, where we're going to collect more types in the future
that are meant to be re-exported as public API in the sixtyfps-rs and the interpreter crate.

Implement `sixtyfps::ComponentHandle` for `ComponentInstance`, instead of providing a copy of the API.

This also removes `WeakComponentInstance` and enables the use of `sixtyfps::Weak` for weak handles. This has the advantage that `sixtyfps:Weak`'s `upgrade_in_event_loop` becomes available with the interpreter, and the
weak handle is Send.

Also provide some words of documentation.

... to further encourage the use of the `_` pattern when matching.

This allows adding new variants in minor releases without breaking
source compatibility.

cc #431