closes #11, closes #12, closes #13, closes #28, closes #27, closes #26

Remaining tasks:

• move to NPM version of WebScience
• set up a function that creates the rollup configs needed to build the study move rollup config to lib/ #11
• move the options page over to lib move the options page to lib/ #12
• hook up the download button hook up the "download" button for the namespaced datasets saved in IndexedDB #13
• make sure app.config.js has only the modules we're using (specifically RS01)
• review pass over entire repository
• update installation instructions

This PR overhauls the playtest – there's a lot here. It basically became a framework that has solutions for the various dev challenges I've encountered making my own study pototypes.

The idea: create a framework that makes it much easier to collect data through small, easy-to-use modules for playtesting. A module defines a.) a collector (a content script that collects the data), b.) a reporter (a background script that exposes the collection as it happens to the main backgorund script), and c.) a config entry that defines which modules will be active for this build. The config file that defines these things gets rolled up and outputs a functioning study that collects data and stoers it in a namespaced IndexedDB table, which you can manage in the options page. See bottom of this comment for a screenshot of the page.

More information about the components:

1. collectors – these content scripts are responsible for collecting data from a page. The Collector class makes it easy to hook into the PageManager events and respond accordingly. It also has a basic state management method that is more functional, leveraging immer.js's produce function to create new proxied deep copies of the state.
2. reporters – background script modules that listen for new messages from collectors. Their only requirement is exposing an addListener function. The Reporter class makes it easy to pair with a collector & define the schema, but it is not strictly necessary to even use the class.
3. app.config.js – defines what data collections we want the system to use. It looks for a module's source (*.collector.js and *.reporter.js if these scripts exist) and handles all the rollup stuff needed to turn the modules * config into a working playtest study.
4. rollup – handles the framework's modules and outputs a functioning, multi-module "study" style extension with additional data management.
5. storage – data collected by the collectors/reporters makes its way into a namespaced table in the extension's IndexedDB.
6. options page – enables management of the data collected locally in this playtest.

This framework should enable us to flexibly try out new data collection modules pretty quickly.