Sort out no_std support

[nicoburns]

Currently parley has a std feature which can be disabled, and we are paying the maintenance cost of maintaining that, but it can't actually do anything useful when that feature is disabled. I would suggest that:

• Nothing in this repo ought to be support in "no alloc" configurations
• Fontique ought to work as "font database" and support querying, manual loading of fonts, etc without std. Backends should require std as needed (probably all of them?).
• Parley ought to to fully function in "alloc but no std" mode. It ought to have no conditional code to enable this (except perhaps some conditional imports from the alloc crate). Parley will still transitively require std in some cases through it's dependencies.

[waywardmonkeys]

See problem exposed in PR #124.

[xStrom]

I think a good first step is to get things actually compiling with no_std. That will allow us to at least not regress thanks to CI checks. Adding actually useful functionality can be a step after that.

With that goal, I managed to get fontique compiling in #158.

Now parley is more tricky, because swash does not yet support no_std. I started to add that support, but then found that @waywardmonkeys is already ahead of me with swash#63. Once that lands we can move forward with doing the same for parley.

[DJMcNab]

What is the state of this now? Is it only waiting on a release of swash containing dfrg/swash#63?

[waywardmonkeys]

That is at least the next step!