`cuprated` binary

[hinto-janai]

What

This PR will flesh out the skeleton of the Cuprate node application binary.

This includes:

• [ ] Command line argument parsing and documentation (./cuprated --help)
• [ ] Mapping arguments to specific code paths
• [ ] Configuration file (de)serialization
• [ ] CLI & on-disk config mixing and validation
• [ ] Disk permissions/umask handling
• [ ] Documentation handling (./cuprate --docs opens in browser)
• [ ] Graceful shutdown at end of main() and any end hooks (e.g flush data)

It may also include:

• [ ] Logger initialization
• [ ] Initial thread spawning
• [ ] Internal Cuprate initialization (force lazy statics, assert start conditions, define order of processes, etc)

Q/A

Some open design questions that don't have answers yet.

Q = question A = probably the answer but undecided

Q: Binary name?
A: `cuprated`

Q: Default disk permissions?
A: Admin/User read/write on Windows, `umask(027)` or `rwxr-x---` on Unix

Q: With overlapping/conflicting `--cli-flags` and disk configs, which takes precedence?
A: CLI - disk config gets parsed first, then CLI overrides

Q: Config file format?
A: TOML

Q: How is documentation stored/opened by the binary?
A: Similar to rustc: ZIP -> uncompress into `~/.local/share/cuprate` or equivalent -> open

Q: Does the binary handle log init?
A: As we have direct access to `--log-level` and such, it would be easier

Q: Does the binary spawn _all_ threads? (as opposed to spawning a few key ones, which spawn others)
A:

Q: Should `cuprated` be able to parse and use `monerod.conf` (or at least translate it into `cuprate.toml`)?
A: Probably no - even if yes, it's very low priority.

Q: What configurations and `--flags` should `cuprated` support in the first place?
A:

Q: Should `cuprated` directly handle X.509 certificates and keys (and thus HTTPS/SSL)?
A: Yes.

Q: Should `cuprated` write to an on-disk log file or only STDOUT?
A: Both on disk and STDOUT.

Q: Should `cuprated` be able to do local JSON-RPC invocation (e.g `./monerod get_info`)?
A: Probably not.

Q1: Should `cuprated` mix in ENV_VAR's with the CLI/disk config (e.g HTTP_PROXY)?
Q2: If yes, what takes precedence?
A2: CLI > ENV_VAR > disk

Q: Should `cuprated` contain a JSON-RPC HTTP(s) client (that is more user-friendly than curl)?
A: No, should be in `cuprate-cli` if at all.