Make backends pluggable via FileSystem ctor

[humphd]

The rewrite for different backends landed, and I think we can take it a bit further. Where we currently have FileSystem, IndexedDBFileSystem, and WebSQLFileSystem, I think we only need/want FileSystem. To get there, I propose an API change like so:

// Create a FileSystem using whatever backed the current browser supports
// (one of IDBFS.StorageProviders.IndexedDB or IDBFS.StorageProviders.WebSQL)
var fs = new IDBFS.FileSystem({ name: "local" });

// Create an IndexedDB FileSystem explicitly
var idbfs = new IDBFS.FileSystem({
  name: "local2",
  db: IDBFS.StorageProviders.IndexedDB
});

// Create a WebSQL FileSystem explicitly
var websqlfs = new IDBFS.FileSystem({
  name: "local3",
  db: IDBFS.StorageProviders.WebSQL
});

// Create a "RAM Disk" FileSystem explicitly
var ramfs = new IDBFS.FileSystem({
  name: "local4",
  db: IDBFS.StorageProviders.Memory
});

In the case that no db option is provided to the FileSystem constructor, it will figure out what it supports (e.g., IndexedDB or WebSQL). However, if an explicit constructor function is provided for a Storage Provider (one we provide, or a custom one we don't--someone could add localStorage if they wanted without changing our code) the FileSystem constructor will attempt to use that instead. This will also make it possible to test different providers easily in tests, provide mocks if we want, etc.

The FileSystem creates and holds a reference to a db object using the appropriate Storage Provider constructor. All storage operations are delegated to this object, essentially what is happening now with IndexedDBContext. This also means that we can flatten the code paths for IndexedDBFileFystem, WebSQLFileSytem, and FileSystem into FileSystem. The advantage of this is smaller size, but also a much simpler model for extending with new types of storage providers, since you only need to send a new db into the FileSystem constructor vs. having to also implement a FooFilesystem, deal with scope issues on internal function calls in fs.js, etc.

The db object will provide ways to open the database, deal with transactions (real or simulated, depending on backend), do operations like get/put/delete, obtain a context to pass around to fs operations.etc. It won't be a large object, but will encapsulate all the backend specific bits of working with data. The FileSystem will do everything in terms of db operations when needing to work with a backend. There won't be any need for more specific types of file systems.

[modeswitch]

This looks good. As part of this, it might make sense to start splitting things into separate files as well. I'll review + merge this ASAP as soon as you're ready.