Set up a new development environment for working with Field Modules

[jgaehring]

Since implementing #446 there is no longer a way to work with the Tasks module (or any other field module) in a live development environment that watches for changes in the field-module-tasks directory and hot reloads the app in the browser.

Way back when we had separate farmOS-client and farmOS-native repositories (see #92), I had installed the native repo as a devDependency in the client repo, and a similar thing could be done here, where field-module-tasks could install field-kit as a devDependency and then load Tasks during compilation. I don't really like that, since it's a step backwards towards the whole notion of a "buildtime" module, which doesn't really make sense and constrains the API for field modules going forward.

Ultimately, I'd like to mock the farmOS endpoint, /api/field_module/field_module, and serve up some JSON that just points somewhere else on the file system, rather getting proxied to the farmOS server on localhost. That may take some doing, however, especially if it depends on having source maps set up properly, which should be done regardless, but in the interest of time I might have to strike some kind of compromise between those two options.

[jgaehring]

Ultimately, I'd like to mock the farmOS endpoint, /api/field_module/field_module, and serve up some JSON that just points somewhere else on the file system, rather getting proxied to the farmOS server on localhost. That may take some doing, however, especially if it depends on having source maps set up properly, which should be done regardless, but in the interest of time I might have to strike some kind of compromise between those two options.

I just went for it and set up the mock server, since I needed it to serve the entry point that calls window.mountFieldModule() anyways. It certainly wasn't the hardest part of the setup, but in any event, this is all resolved now. See #496 for the full history.