Refactor Selection Service

[LuminaSapphira]

Currently the selection service is not consistent with current conventions, and needs to be refactored to handle multiple terms. The final result should allow for the selection of sections across terms, but they should be compartmentalized to avoid contaminating the schedules of other terms.

[LuminaSapphira]

I'm restructuring the storage to be in-memory and synced to local storage (in contrast to the way it is now: operations are done directly on local storage). It will be a Map from the term id to another class, which will manage the data per term. Inside that class will be another Map from the listing id to the section ids selected for that listing. This allows simple generation of [section, listing] pairs as needed by the conflicts service, as well as quick array generation of all selected sections by joining Map.values() together, as needed by schedule view. The selection service itself will take optional parameter termId on most of its functions (undefined => selectedTerm from term service) and pass it to the appropriate instance in the map. Backwards compatibility will have a high priority, so (hopefully) the most I will do to affect this is change function names to be a little more clear what as to what they are for.