Combine logging config and implementation in arti lib crate

This is a demo, pursuant to #375 (closed) and #285 (closed).

One of the bad things we have going on is that arti's configuration is in a different crate to its implementation. (This is unlike the tor-* crates, each of which define and expose their own config structure.). Here is a demo of how things improve if we make arti like the other crates:

Putting the logging configuration and implementation together abolishes the public interface between them. This wasn't a proper interface anyway, as any changes would have to be made on both sides anyway. As a bonus, abolishing this as an API gets rid of handwritten accessors whose only purpose was to pretend that this was a proper arms-length interface.

I think in fact this wants to be in arti, but putting LoggingConfig in arti now would involve moving ArtiConfig. In this revised branch I move ArtiConfig to arti.

If the principle of putting this configuration and its implementation together is accepted, then we will want to do the same to the rest of arti_config/options.rs.

I do think all these things including ArtiConfig should be in the arti library crate. Merging this MR now seems to imply moving things again. An alternative to that would be to move ArtiConfig (and arti_defaults.toml) first. I didn't want to do that for an RFC MR though.

If we go in this direction, arti_config will retain knowledge of the default configuration sources, and the machinery for handling config on the command line, but not knowledge of any specific configuration items. Whether to retain that as a separate crate, or fold it into arti as well, could be a decision for the future.