Moves dependencies and submodules behind Features

[Hate9]

Glowpub is potentially quite useful as a library, but it has a lot of dependencies, which makes it a very large import if you only need a small subset of its functionality.

This PR moves everything behind Feature flags, so you can choose to import only the utils, or only the auth code, or even just the base types if you need those for whatever reason.

The gen flag could probably be split up into a few sub-features for independent submodules, but otherwise I think this PR works well.

[QuartzLibrary]

Hi, could you elaborate on what the goal is?

People usually want to avoid deps for one of three reasons:

• Compile time.
• Building on different targets (here only wasm should be an issue).
• Security, by reducing the attack surface.

In general I am not very strict with deps as long as my iteration cycle is not impacted (which it normally isn't if incremental compilation works well enough).

Some notes on the PR:

• I don't think it makes sense to gate everything behind features. types, for example, should always be available. utils also shouldn't be gated, but it should also probably not be public at all.
• If compile time is the worry, then using minimal features on tokio wouldn't affect anything else and is most likely to provide substantial gains.
• log should definitely always be available, it's a core feature, lightweight, and annoying to add when you need it (changes in Cargo.toml cause Rust Analyzer to recheck everything).
• If building on wasm is the target, gating a couple of dependencies behind a binary features should be sufficient (tokio, clap, and rpassword probably).

Features are also kind of annoying to work with, and I wouldn't trust them to not be broken without CI checking each combination, so, if we want this, let's keep it to a minimum and make sure it's tested. Just adding binary and minimizing tokio should give us considerable gains. I'll also need to add CI when I find the time (Edit: done in #56, you'll want to rebase so that CI can run, and update CI to run clippy on the non-default feature combination).

(As an aside, I will likely be slow to respond for the foreseeable future.)

[Hate9]

Hmm... Good point that the number of Features might be excessive.

I initially made this because I wanted to be able to have the API interaction and EPUB/HTML generation code separate, since it would be useful to be able to import this crate as a library for just the API interaction.

I can simplify things to make it actually just do that, instead of adding too many granular Feature options.

Using minimal features on tokio would also be useful - I might do that, or it might be better for you to, if you know what minimal set of features we would need.

[Hate9]

There, that should be better.