Simplify the organization of our test suites

[zaneselvans]

While updating the development documentation (#940) related to running our tests, it was obvious that our current testing setup is more complex than it needs to be, and it seems to have discouraged people from running the tests, since almost nobody can remember how to do it. There have also been several cases in which someone has gone to the trouble of writing new tests, but they never get run automatically because they aren't put somewhere that our CI setup will run them.

Rather than documenting a complicated system, I'd like to simplify it a bit, and then document a simple system. Changes I'd like to make include:

• Add brief description to each Tox test environment. Can be displayed with tox -av
• Organize the tests broadly into 3 categories: software unit tests, software integration tests, and data validation.
• Make running the "fast" (one year) tests the default, since that's what we almost always do. Other behavior can be elicited if need be by editing the test settings files.
• Remove the option of using a preexisting ferc1 database, since generating a new one for a single year only takes a minute.
• Use existing datastore by default, unless --tmp-data flag is set, and then download fresh data to a temporary directory.
• Read ferc1_to_sqlite settings out of the test settings file instead of generating them dynamically, which is confusing.
• Make sure that --live_pudl_db is still behaving as expected by running the output tests or something.
• Review all of the tests to see if there are multi-year tests that we need to preserve and run somehow in another context, e.g. the test that verifies all the years of automatically generated ferc1 database schemas are compatible with each other. (note that they already aren't really being run that way now if they do exist).
• Create an all-years, all-tables (for ferc1 and eia, but not epacems) test settings file, and a Tox testenv that uses it, in order to make it easy to run the whole ETL against everything, and then also run those tests against that setup too.

See also issue #941 about separating the data validation process from the Tox/pytest setup, since it requires a complete database, and is really a different kind of thing altogether.

[zaneselvans]

This all seems to be working well now! Minor updates to the new docs need to happen to reflect the current setup, which is way simpler.

There are some tests which, rarely, do need to be run against all years of data -- and we didn't really have a systematic way to ensure that was happening in the past. I will create a settings file for all of the years which is part of the test settings, and a tox test environment that uses those settings to check out everything together.