feat: support no-alloc targets

[robjtede]

closes #140

[TechnoPorg]

Hi Rob. Thanks for getting started on this so quickly!

Unfortunately, the patch as-is doesn't quite fix the problem, as the alloc crate still gets pulled in unconditionally via lib.rs, meaning compilation for a small example with the thumbv7em-none-eabi target fails on the no-alloc branch:

#![no_std]

fn main() {
    let test = bytesize::KIB;
}

error: no global memory allocator found but one is required; link to std or add #[global_allocator] to a static item that implements the GlobalAlloc trait
error: #[panic_handler] function required, but not found

Also, from a code review perspective, it might make more sense to put the #[cfg] on the parse module itself, rather than on the individual items within it.

[robjtede]

I guess what I want to know is how much of the library do you need in your no-alloc target?

If it's just the data types that makes things simpler. core includes both fmt::Display and str::FromStr traits so theoretically it might be possible to write these in a no alloc way.

We do run a no-std test on thumbv6m-none-eabi in CI. You can see it in the ensure-no-std/ folder. Can you propose a way to alter that so no-alloc is also checked in CI? Or must we add a new one (sorry this no-alloc world is new to me).