version 1.0

[mirochaj]

This PR represents a major change to ARES that breaks backward compatibility, and so will become version 1.0 once accepted. From then on, the goal is to use semantic versioning, keep test coverage near ~100%, and try to keep up with the documentation better than in the past.

There are many big changes, but the ones that will be most noticeable to people already familiar with ARES are:

• Commonly-used external datasets will now be downloaded and unpacked in $HOME/.ares. Previously, we used a subdirectory within the ARES build directory, which often caused problems on clusters, and was awkward for many other reasons.
• Most of the heavy-lifting of downloading and unpacking external datasets is done with a new command line interface (thanks to @plaplant!), i.e., no more remote.py script. For example, to download NIRCAM transmission curves one can simply type ares download nircam from anywhere on the command line, and they will be neatly tucked away in $HOME/.ares/nircam.
• All "simulations" will now be run through a unified class, ares.simulations.Simulation, which has methods for common models of interest like get_21cm_gs (to run global 21-cm signal models), which replaces the previous approach of calling individual objects like Global21cm and then executing the run method.
• Given the diversity of models that can now be run with ARES, one is no longer allowed to initialize a Simulation object without supplying any parameters! The workflow is instead to start from a base set of parameters, likely drawn from a ParameterBundle, with modifications applied subsequently.
• The submodule in charge of handling data from the literature, litdata, has been moved to ares.data, with the primary function read. So, to pull in dictionaries of data, one can do something like, e.g., b15 = ares.data.read('bouwens2015').
• The confusingly-named but very-important submodule ares.static has been renamed ares.core.
• Many seemingly-clever but in the end needlessly-confusing functionalities have been completely gutted, which hopefully makes debugging much easier for the non-expert user. For example, some ares.populations classes had a __getattr__ method that could be used to find and even create non-existent attributes based on the contents of the parameter file. The hope here was to allow anything to be parameterized, and alleviate users and developers from having to implement new functions in ares.populations classes all the time to accommodate this. Things are more cumbersome now (i.e., there are many get_<something> routines in ares.populations objects), but I think much, much clearer.
• Throughout, the naming of class methods is much more intelligible and consistent than before. For example, routines that do a lot of heavy lifting are generally named get_<something>, lookup tables are attributes named tab_<something>, and routines that create big lookup tables are called generate_<something>. You might need to update some call sequences if you access internal methods much, e.g., LuminosityFunction is now get_lf, StellarMassFunction is now get_smf, and so on.
• There is a new submodule, ares.realizations, for (you guessed it) generating realizations of ARES models. This is extremely preliminary and you'll find no documentation for it. Contact me if you're interested.

This PR is not yet ready for review, but I wanted to get the ball rolling and to see how the tests were doing. I'd like to continue updating documentation, tests, and potentially port to PyPi as well. I will keep updating until it is in slightly more respectable shape. In the meantime, if any recent users have some spare cycles and want to check things out, any and all input is totally welcome and much appreciated! @plaplant @gjsun @JudahRockLuberto @JJHibbard. You'll probably want to build the documentation locally in order to see updated examples.