Migrate Webpack base config from native repo to client

[jgaehring]

Resolving this issue is contingent on fixing #22 first.

Note that the main build script (not build-mobile) will also need to be migrated. The output of this should be targeted to the /dist folder, and package.json.main should point to that new location so that projects importing the client as a library can find it.

This whole process might be made a lot easier and cleaner by re-scaffolding the whole project with vue-cli, to eliminate any unnecessary configurations, and also make it a snap to reestablish the linter (#1) and test suite (#4).

It's worth considering whether Rollup might be a better option at this point, since conventional wisdom seems to favor it for bundling libaries, instead of Webpack.

[jgaehring]

Splitting the parts of the Webpack config that handled the native and client repos' separate build processes turned out to be a lot stickier a problem than I had hoped. The biggest hurdle was in maintaining some kind of development environment that would listen to changes as they occurred in both the native and the client repo. Since the client is becoming more like a library for loading plugins, it really can't provide a browser-based development environment until an implementation, eg the native repo, calls it and provides those plugins (although it also underlines the need for proper unit tests). So it makes most sense for the dev server to run from the native repo. It didn't occur to me for the longest time I could just set a watcher on the client's build script, so it would rebuild on any changes in the client repo, and that would trigger the hot module replacement in the native repo's dev server.

I still need to document that whole process, and there still a lot of rough edges, but the basic requirements are all in place now:

• it has all its own dependencies, and only its own dependencies (barring some cruft I plan to remove when I get to Update npm packages and remove unnecessary deps (eg, Vue, etc) #31)
• it can build itself
• changes made there will be hotloaded from the native repo's dev server
• bonus points for now having the linter (Quick Observations #1) and test suite (Feature/spa loader #4) re-established! Because in the course of things I wound up re-scaffolding the whole client repo with vue-cli, and was able to install them super easily.

Still want to work on:

• have source maps and Vue tools available
• use more of a dev config for the watch script
• target more output formats, with minified and un-minified versions for CommonJS, UMD, AMD, etc
• create a similar configuration for each of the plugin's, so they can eventually be treated as their own libraries as well

Finally, in the process of sorting all this out I read more about the concept of monorepositories, and feel like we may want to end up there if we start breaking things up into a lot of independent view components and plugins that can easily be swapped in and out. There's a great article on all that, called Monorepos in the Wild, and a tool called Lerna, made by the same folks that make Babel, which could make the whole project a lot easier to manage. Regardless, I think the work here will pay dividends in having separated the build and development processes, by enabling us more freedom to choose down the road.

[mstenta]

(Transferring all issues from old repository. See #92)