Add no_std support for lyon_tessellation

[konall]

• Removed lyon_tessellation rigid dependency on default features from lyon_path
• Added new crate feature std, enabled by default, which enables std feature of lyon_path dependency
• Replaced imports from std with their corresponding imports from alloc and core
• Required enabling feature std to display printed debug assertions
• Annotated some test functions with #[cfg(test)] to be explicit about their dependence on std

[konall]

I've noticed through testing that the final remaining blocker on no_std support is the dependency on thiserror, which currently does not support it.

A possible alternative would be to use a different error handling (eg: Snafu) that is behind an optional no_std flag so as to be a non-breaking change (it would have to be behind a feature flag because it is currently not possible to exclude dependencies based on feature flags, only to include them: rust-lang/cargo#1839)

I haven't spent enough time looking lyon_tessellation infrastructure to know if swapping out for manually-implemented Errors is a possibility, but that may also work?

I'd be very interested in making this crate no_std compatible so let me know if any of the above are an option you'd be willing to consider.

[konall]

Having read a bit more into this, I've successfully gotten lyon_tessellation to compile for no_std without any breaking changes (as far as I can tell).

The two big changes were:

• hand-writing the error implementations that thiserror provided, but feature-gated to std- as asserted here, this is not a breaking change, and I hope that the new error module is concise enough that it doesn't introduce any significant maintenance burden
• adding a dependency on num_traits for no_std floating point and trig operations- as mentioned above, this dependency unfortunately can't be disabled for std targets, but I copied the exact same way this is set up in the lyon_path crate so I hope it's ok

I'd love to see this merged, so please let me know if there's anything that needs fixing, thanks!

[nical]

Hi, thanks for this PR, I haven't had time to look at it yet but I hope to get to it soon.

[nical]

Looks good, thanks!

[konall]

Thanks! You may have noticed but with this change the entire lyon crate is now no_std compatible (ignoring the lyon_extra crate of course)- it should be trivial to update lyon to reflect this but let me know if you want a PR submitted

[nical]

I hadn't noticed! I'm planning to add a fair amount of stuff in lyon's meta crate so let's not mark it as no_std compatible now since I don't know that it can remain that way later. For lyon_algorithm, you are welcome to make the change if you want to, but it's also fine to wait and see if anyone needs it (and submits a PR for it).