Turn the no_std feature into default-enabled std

[kupiakos]

This gets #68 over the finish line to being a functional #![no_std] library.

This also:

• fixes the no_std not being enabled due to a swapped cfg_attr.
• tests this builds with a #![no_std] binary.
• A lot of the cfg's have been removed due to being unneeded.
• adds a new dependency
• updates the version to 2.0
• adds a ci command to to use cargo-no-std to check no-std

Some notes on changes from #68:

Everything in core is a subset of things in std. core is available in std environments, so if you're building a no_std-compatible library, it's best to import things that don't require std from core.

core2 is also meant to be used as a no_std polyfill with its std feature. That is, you can reference core2::io, and if the std feature is enabled, it actually references std::io.

[rmsyn]

Some minor edits for imports to fix std/no_std test builds.

There is also a needed change in a file you didn't edit, src/lz77.rs:

    use crate::deflate::symbol::Symbol;
+   #[cfg(not(feature = "std"))]
+   use alloc::{vec, vec::Vec};

Otherwise, LGTM. Thanks for adding the example binary, and test runner!

[rmsyn]

@kupiakos Please run both std and no_std test builds, and make sure they complete successfully.

# std tests
cargo test --all

# no_std tests
cargo test --all --no-default-features

They complete successfully with the suggested edits in this PR.

[kupiakos]

@rmsyn PTAL at the changes. Again, my apologies on missing the #![no_std] tests. In my defense, most of the embedded unit tests I work with don't have a std feature, they're default #![no_std] and so I forget cargo test --no-default-features is even an option 😄

@sile Can you check that the Github workflow works as intended? Not sure if @rmsyn can.

[rmsyn]

PTAL at the changes.

LGTM, all the tests pass under std and no_std builds. Not sure about the CI runners, but they look like they should work now.

edit: one kind of hacky way to see if test runners work is to open a PR against your fork of the repository. It should run the CI. Not a local way to run CI, but could be useful.

[sile]

@kupiakos Some CI checks have failed (in case you haven't noticed yet).

[kupiakos]

Sorry for taking so long to get to this. It was a ~mistyped flag~ many things. I'm figuring out testing the CI on my PR as suggested, though feel free to approve your workflow when you see this.

[kupiakos]

@sile I've confirmed CI works on my end, and have squashed all the fixup commits for a cleaner history.

[sile]

Thank you too, @rmsyn, for your review!