chore: use workspace features more intensively in crates

[JarvisCraft]

Description

This PR:

• enhances the use of new Cargo Workspaces features in crates/;
• configures Cargo Workspaces for examples/ directory.

Limitations

Currently, due to a Cargo bug/design, when building with cargo build in a workspace directory, feature unification happens across all packages causing all of them to have alloc feature enabled thus leading to a compilation failure on crates which don't configure the allocator.

This does not happen when building packages independently (i.e. cargo build -p foo or cd foo && cargo build).

I consider this acceptable as for now since examples are already built one-by-one, although I will report this problem to Cargo Issues so that it can be resolved in the future.

More on cargo zulip and cargo issue.

[dcoles]

Currently, due to a Cargo bug/design, when building with cargo build in a workspace directory, feature unification happens across all packages causing all of them to have alloc feature enabled thus leading to a compilation failure on crates which don't configure the allocator.

That's a particularly annoying bug. Unfortunately, I can see this constantly being reported as a bug if cargo build (and family) don't work correctly in the examples directory.

This might be good enough a reason to move all the examples into crates/flipperzero/examples and then create a dedicated template project for people to use as a reference.

In the past we've talked about whether we should just always enable alloc for the flipperzero crate. From a quick experiment, it looks like just enabling the alloc feature and defining a #[global_allocator] does not have any noticeable effect on the binary size. The main annoyance is that every binary needs to explicitly extern crate flipperzero_alloc, even if not otherwise used.

[JarvisCraft]

In the past we've talked about whether we should just always enable alloc for the flipperzero crate. From a quick experiment, it looks like just enabling the alloc feature and defining a #[global_allocator] does not have any noticeable effect on the binary size. The main annoyance is that every binary needs to explicitly extern crate flipperzero_alloc, even if not otherwise used.

Yup, currently I have no sane ideas how to enhance this except for a funny macro like:

#[macro_export]
macro_rules! default_allocator {
    ($crate_name:ident) => {
        extern crate $crate_name;
    };
    () => {
        extern $crate::default_allocator!(flipperzzero_alloc);
    };
}

[JarvisCraft]

I've also bumped the version of the nightly so that newly stabilizzed features (such as sparse registry) can be used.

[dcoles]

I've also bumped the version of the nightly so that newly stabilizzed features (such as sparse registry) can be used.

I was hoping with Rust 1.68.0 we could drop the nightly requirement, but turns out we still need nightly for -Z no-unique-section-names=yes. I should ask if it would be possible to stabilize.

[dcoles]

Merged. Thanks for the PR @JarvisCraft!