Apply "module Config pattern"

[bartelink]

This applies a set of code patterns that I've been applying in recent times in a system I'm building that consists of the following elements:

• the Domain project defines a module Config which defines a Store DU which defines the set of stores its connectable to. This would be Memory plus one or more concrete ones
• Each module Aggregate has a module Config which surfaces a create method that is passed a Store DU instance and does the appropriate wiring (e.g. if using Cosmos and Snapshots makes sense, it means that logic is close to the aggregate)
• the Domain project needs to reference the relevant concrete store package e.g. Equinox.CosmosStore. NOTE there should be no logic in the Domain project actually connecting to the store - this is purely to allow one to wire the specific ways the caching or snapshotting needs to work per aggregate in a single place

When Domain is organised in this manner, the following becomes clean to do:
a) define high level tests that operate in-memory which exercise significant workflows in a system (often cross-aggregate), using a Memory Store
b) define integration tests that use the concrete stores
c) define Web host and/or Reactor apps without repeating wiring logic (if it needs to be shared, a .Infrastructure project can have that specific wiring)

A better demo app is needed, and will arrive in due course; for now, the closest thing is the layout of the equinox-shipping project

Includes:

• Update to FsCheck 3.0, chiefly for async support
• Applying lots of FsCheck techniques from @pblasucci's fantastic blog post and samples