Add script to generate StationXML files from cube metadata

[liamtoney]

This PR adds a new script, cube_stationxml, which generates and validates a StationXML file from input miniSEED files and metadata. The idea is that the StationXML file generated by this script, together with the miniSEED files generated by cube_convert with the --earthscope flag, form a complete package ready for EarthScope upload.

Furthermore, it is probably best practice in general to store and work with these data in raw counts and use the StationXML file to remove the full response / sensitivity as appropriate.

I'm opening this PR as a draft so that we can have some time to discuss in this thread and make modifications / improvements as needed — there's no rush on this. You can view the help menu for the new cube_stationxml script in this section of the updated README.

Here are some key notes on this PR:

• The sensor_sensitivities.json file has a new format. In addition to sensitivity in V/Pa, the frequency of the sensitivity measurement and the sensor model are also included. Chaparral calibration sheets give this frequency info. The new content in this file is required for forming the StationXML file (e.g., we need the sensor model to look up the proper nominal response in the EarthScope NRL). I've done my best to update the UAF-specific file in here but set values to "?" and -9999 if I didn't know what they were — should be easy enough to fill in.
• The code only works for single-channel DATA-CUBE³ deployments. This avoids issues related to parsing different sensitivities for the same digitizer, e.g. Only one sensitivity used for multiple-sensor setups #9, and also linking digitizer-derived GPS coordinates to a sensor (see below). The script checks for this and should error out if it sees a multi-channel cube.
• Currently, the script reads in digitizer-acquired coordinate info from the output miniSEED directories (so it expects that cube_convert was run with the --grab-gps flag). However, if another coordinate source is used (e.g., external GPS survey), we'd want to allow the user to provide those coordinates instead.
• Requires development ObsPy until v1.5.0 is released (see note at top of script) — unfortunately I don't think there's a good workaround for this but could re-examine if it's a pain.

This PR closes #1 (at long last!).

[liamtoney]

• Requires development ObsPy until v1.5.0 is released (see note at top of script) — unfortunately I don't think there's a good workaround for this but could re-examine if it's a pain.

This might be coming soon: obspy/obspy#3681 (comment)