Starting to break Ambidex into its own project
Creating Cacher

I think I've found a better way to solve this that doesn't require
caching files, but I'm committing this anyway so I can find it later if
I need it
IT WORKS(ish)!

I still need to do the plumbing for static folder mapping, but otherwise,
Ambidex is doing what it's supposed to do (serving a single Routes instance
on both the client and server).

In order to prevent Ambidex from importing its own shadow copies of React,
all its React dependencies are imported from the caller using
settings.FILESYSTEM_PATHS["MODULES"].  Before we ship this, I'd like to
find a cleaner solution that

a) doesn't pollute settings, and
b) isn't so fragile
Point settings.context at our own __dirname to prevent lookup issues when called externally
Making `settings` global so they can be accessed from Routes et. al.
Attempting Context Locals!

We need a way to pass settings back from Ambidex into the routes.  Since
modules in Node can't close over one another, I tried to fake it by
abusing the error system to implement context locals.  Unfortunately,
the stack expires before any asynchronous code is run.

I'm committing this for posterity, and to bookmark it in case I need
this solution later.

As for passing the settings down, I need a new strategy.  The most
likely candidate is to create AmbidexRoutes, which wouuld inject a
settings prop onto every route it's passed, then wrap them in <Routes>
and return that.  Not sure yet if it'll work - I should talk to
@mjackson about it.
Passing settings down with AmbidexRoutes.@handlerProps

I was trying to force the calling app to pass its instance of React and
ReactRouter into the module so we could make sure we don't end up using
a different version than the calling app.  Then, I realized my inability
to just use the calling app's versions is because of a bug in how
`require` works from an `npm link`ed package.

I can access the correct versions if I move my repo into the calling
app's node_modules (which is how it will be used by most people anyway).
Therefore, I'm going to back out most of these changes to instead use
the simpler `require` (which is all I wanted all along).
Using react-hot-loader 0.4.5

Makes the /\.jsx?$/ loader introduced in 8825d4d3d58512e7b13f85c1a104eeef8e57ae70
work correctly.
Removing unused dependency on my-local-ip
Removing ambidex.forModule and <AmbidexRoutes>

Most of the clever stuff I've been doing in this repo has been trying to
work around [npm#5875](https://github.com/npm/npm/issues/5875).  Now that I realize this is a legitimate bug in
npm (with a simple workaround - develop your library in its calling
app's node_modules folder), I can remove all the clever shit and let
Ambidex shine through.
Creating mach.contentCharSet to fix encoding issues

See https://github.com/mjackson/mach/pull/43
Point react-router and mach at my branches until my PRs are accepted
Adding reminder to keep Ambidex safe for public consumption
Promisifying Ambidex
Promisify the readme
Use Promises instead of readFileSync in webpack.run.then
Make sure all errors go through rejectInitializationPromise
Making devDependencies into optionalDependencies

devDependencies was fine before Ambidex became its own project, but now
it's useless since our calling app might be in dev and want these
packages.

optionalDependencies will try to download themselves, but still be OK
if they can't be installed (since you can still use Ambidex if
ENABLE_HOT_MODULE_REPLACEMENT is turned off).
Ignore Sublime project
Fixing Webpack errors for loader requires