Add --no-html flag and HMR path support

[bwendt-mylo]

Re: --no-html flag
See #278 for context.

Re: HMR path support

TLDR; Cannot receive HMR updates when bundled JS is served from a different server/port

Here's my dev setup.

I've got an Express server running locally (localhost:3000) that serves up content based on configured modules. A module consists of a manifest file that references the bundled JS file for that module.

Example manifest.json file loaded as a module for a given page:

{
  "src": "//localhost:8080/app.js",
  "title": "Cool New App"
}

When the Express server renders the content of the page it injects a new script tag with the src attribute set to the value of the src property from the manifest.json file. This will load the script and allow the app to be rendered into an existing DOM node.

While developing a new module, I'll run npm start -- --port=8080 on a newly created nwb (preact) app. This means that I can access localhost:8080 during development and utilize HMR functionality. What I can't do is load the app.js served up by npm start from within a page in my locally running Express server and utilize HMR functionality because the path for the HMR client is monitoring localhost:3000/__webpack_hmr.

Thus, it seems that if you're running on a non-standard host and/or port, a proper path configuration should be passed along to allow HMR to work.

Thoughts?

[insin]

Do you mind re-doing these as separate PRs against next without the merge commits?

--no-html support is now a single line change to src/appConfig.js (plus a line for docs in cli.js and Commands.md next to --no-vendor)

src/createServerWebpackConfig.js is now set up with a hmrURL variable which is ready for providing a full HMR path in.

You've already done the work for these, so I'd rather you get the commit credit for them, as you're a first time contributor and I have a bad habit of undermining PRs in the next branch.