I knew this in the previous commit, but I thought their parent class, TimeseriesFactory, could handle arbitrary keywords (i.e., it had a kwargs argument to vacuum up unrecognized keywords). I was mistaken.

These will be passed to IO factories if those factories accept them. As of this commit, only Edge and MiniSeed factories honor these options. Others should be updated to accept these, and apply them in a similar manner.

- align timestamps more consistently for "update" intervals
- (related) add "interval" option to get_realtime_interval

Better mapping of publication level to imag or imf. Compression and Fill Value constants. Code simplified.

tweaks to accept output_args. temperature-type elements as a nonstandard geomagnetic field element instead of as Temperature cdf variable

Added a warning message for FDSNFactory in the case a user is requesting data from the command line and assigns innaporopriate arguments.

For years, when invoking geomag-algorithms' update mechanism, inputs
were pulled and checked from the run_as_update() method inside the
Controller class. I never understood this. It seemed to break the
logic of the update mechanism if no inputs were available for the
current inteval/gap. This might even be the source of noted issues
where running back-filling scripts didn't behave as expected, and
those scripts needed to be run multiple times.

What's more, the run_as_update() method logically seems like the
most appropriate place to read *outputs* and check for gaps. Whereas
the run() method seems like the most appropriate place to read
inputs, apply algorithms, and write out outputs.

In any case, this change should not break any existing code. It
should only allow the update mechanism to complete, every time, and
as originally intended, rather than be short-circuited when input
data are missing for the current interval (but might be available
for previous intervals)..

This broke when changes were made to allow processing data more recent than
the last top-of-the-minute (~8 months ago). The only "updates" that worked
since then were for 1-second data. It's a little bit lazy because it relies
on the output_factory to return traces with proper starttimes and endtimes
(that is, they fall on the tops of minutes). Probably we should be more
explicit in correcting the starttimes and endtimes to line up on expected
timestamps. Pushing this fix now because it has operational impacts.

Controller cannot process sub-minute starttime/endtime intervals.

Previously, the endtime-starttime interval being processed by the
`run_as_update` method would shrink by 1 (second) with each recursion.
This ultimately broke `run_as_update` when processing anything other
than 1-second data, but it wasn't obvious because we rarely had to
actually recurse. There is a little trickery now to ensure that user-
provided starttime and endtime are inclusive of the full first
(most recent) update interval, while subsequent, calculated, endtimes
are set equal to the prior starttime minus specified output_interval
(e.g., 'second', 'minute', etc.).

It turns out that none of the factories currently being used in
production expects bytes as input, and in fact, Util.read_url()
converts everthing to a string anyway, so a BYTES-oriented input
would couldn't not possibly be working. So, just remove all use
of BYTESIO, and instead use only STRINGIO.