Split XENON-specific algorithms to straxen

[JelleAalbers]

The strax / straxen split

This removes highly XENON(1|n)T specific code from strax, such as the runs db interface, specific plugins, and scripts such the new "eventbuilder". These will now live in a separate repository, which for the moment I've located here: https://github.com/XENONnT/straxen. I've also started adding additional stuff to straxen, such as run selection features from hax.

The idea (see also #48) is that anyone who wants to do XENON1T/XENONnT with strax will install straxen (and through it, strax). People who want to use strax on other TPCs (or maybe on something completely different than XENON TPCs) can build their own processor / analysis framework on top of the core strax package.

I'm not entirely sure where to put the basic algorithms, such as hitfinding and baseline correction. For now I've left them in strax, since you probably wont want to rewrite these when you start on a new TPC. On the other hand, we might want to add some very XENON-specific upgrades to these at some point. If so, these new versions should go to straxen instead.

We can vote on the name of straxen at some point. Other options might be xestrax or maybe xstrax. I find myself occasionally mistyping straxen as xestrax, maybe my unconscious mind is trying to tell me I picked the wrong name...

Unfortunately straxen's docs are currently not building, because strax's pip install does not work, see #105. Once this is merged, I will release strax v0.6.0, which should fix this.

Additional features

To support the new features in straxen, I've added a few things here too:

• A new list_available method to lists all runs that have a specific data type available. Support for DataDirectory is included, straxen adds support for RunDB.
• A new context option forbid_creation_of, which you can set to forbid creation of some new data types. For example, if you can't find raw_records, the current default behaviour is to start the DAQReader or paxconverter. This often isn't the most reasonable, e.g. on an analysis server. With this option, you can throw an error instead if this were to happen.
• A new run_metadata method to get run-level metadata. We already had support for run-level metadata, but there was no method on Context for getting it. In straxen, with the runs db registered, this gets you the run document.
• A few smaller fixes, such as removing print statements and clarifying some keyword arguments.

[tunnell]

I read through the changes. I think this is exactly what we need.