Restructure to allow root entry and correct sub directory entry paths

[talves]

We can now have a root entry point at the same time as having a sub directory entry points.

Here are the highlights of the changes

• Fixes the relative paths to file loader assets no matter where the entry point is in the path
• An absolute path will be used for the webpack-dev-server
• Relative paths will be used if wanted by default in the webpack build into /dist
• A public relative path is created based on the entry point context rather than absolute from root context
• Added the boilerplate example with both one root and one sub directory entry point
• It will allow for any number of levels deep in the directory structure
• Each entry point can now be saved as it's own module and will install to any virtual path if all file-loader assets are relative to the entry

Notes:

I believe there should be a fix to the file-loader as in my fork here talves/file-loader to make sure url paths end up in a more direct relative path to the index.html entry point. (i.e. images/... vs ../boilerplate/images/...) by using the root context (context + /boilerplate) to resolve the url path.
The change is not required, but allows us to have a stand alone entry path without having to be dependent on the public path being set in the resource file in the file loader.

In the current solution, we will not be able to export a module to just any path if we do not use the new file-loader changes.

[talves]

@markmarijnissen any progress on review? Not a problem if you are too busy, just was wondering.
I have already created 4 proof of concept apps with it as of today and all is well.

[markmarijnissen]

Hi @talves - I only quickly read through the code changes - I did not actually test it.

Considering that I'm short on time, your pull request is well documented, and you actually tested it already on four apps of your own, I've decided to make you a collaborator. The Pull Request in in line with the current philosophy; i.e. support multiple bundles. (For prototyping, tests, back-ends, websites, etc).

To sum up my philosophy in one line:

    The seed should be as powerful and flexible as possible to support many use-cases, but power and flexibility may **never** cause more complexity or idiosyncracy in the seed. 

The config itself should stay short and easy, and additional functionality should come in the form of webpack loaders or plugins.

@everybody:
If the current request causes any problems, I welcome anybody to submit an issue. I have the intention to fix any issues quickly, and I hope @talves can help out as well.

[talves]

@markmarijnissen thanks Mark, of course I will help out as needed. Funny, there was an everybody user. :)