Redesign and improve the Gradient type and friends

[Ogeon]

It should have about the same API as today, where it still makes sense, but overall modernized. Also fulfill this:

• make it #[no_std] enabled
• support more than just linear interpolation
• the Take iterator should be inclusive, meaning both ends are part of the output for n > 1
• support slicing with at least x..=y, but other ranges may also make sense

The first two points may go hand in hand, by replacing the internal Vec with some input collection.

[okaneco]

To learn more about [no_std], I looked into making gradient [no_std] enabled and built it successfully for thumbv6m-none-eabi. Since the alloc crate has been stabilized, you can use some collections like Vec with no_std. That required changing instances of std::vec to core::vec in gradient.rs, configuring the alloc crate behind a feature flag in lib.rs, and adding some helper code in the no_std_test.rs like the alloc error handler. For data structures and no_std, it seems like the choices are use alloc and make users specify their own memory allocator in their crates/runtimes, or bring in a crate like heapless for your internal data structures (I didn't want to add any new dependencies). I'm very inexperienced with this though, this is what I can gather from the current information I could search.

The no_std_test fails to compile for x86_64-unknown-linux-gnu target in the same CI build. It doesn't seem like there's a solution currently for the undefined reference to '_Unwind_Resume'. It seems to be an issue with the linker and I couldn't get the rust-ld linker to work as I believe you'd have to specify library locations in the VM image. eh_unwind_resume doesn't seem to matter for helping linux-gnu build and thumbv6m didn't need it to build. I don't have Linux installed at the moment so can't test it locally, but I can build it locally for x86_64-apple-darwin on nightly.

Here are the changed files.

[Ogeon]

I have never worked with the alloc crate, so I have no idea off the top of my head what this could be. Part of the reason why making the user provide the storage solution is an interesting idea is to not have to deal with supporting allocations at all. It would be up to the user to decide if a Vec or a slice or an array, or whatever else is the most suitable. As long as it's compatible with some minimal API (basically something like something.color_at(x)).

That and the idea of having support for more than just linear interpolation makes me wonder if it's worth the effort to get alloc working, rather than changing the gradient API to not need it.