Cross-module store testing

While working on #292 (closed), I noticed a refactoring was required on the FakeStore to allow for "cross-module testing". I had initially chosen to have the FakeStore only mock one store module, and choose to just ignore calls to actions and mutations outside of the module with root: true. While it allowed for a simple FakeStore implementation, it does not allow the complex interactions we have to use more and more as the store grows.

Proper testing to prevent issues similar to #291 (closed) requires testing across modules, as creating an element with a classification involved a complex process:

1. Dispatch elementsv2/create from a component with a classification ID
2. Call api.createElement
3. Commit elementsv2/set to add the element
4. Commit elementsv2/addChildren with no children to add it to the tree
5. Dispatch classification/create from elementsv2 with an element ID and a ML class
   This is where things were messed up as the whole element was sent and ignored, causing undefined to be sent to the API
6. Call api.createClassification
7. Commit elementsv2/addClassification from classification to add the classification to the element in the store

Component -> elementsv2: create
elementsv2 -> api: createElement
elementsv2 -> elementsv2: set
elementsv2 -> elementsv2: addChildren
elementsv2 -[#blue]> classification: create
classification -> api: createClassification
classification -[#blue]> elementsv2: addClassification

On the above sequence diagram, the two blue arrows represent the action and the mutation that were not properly tested. Cross-module testing alone, without testing for request bodies, might have caught #291 (closed). The tests may not fail, but to a developer, rewriting the tests would make them notice the issue as an element ID was expected and an element was sent. This would make the store.history assertion look strange; #292 (closed) would just make this issue even more explicit.