Separate the browser-facing origin from the dev server's bind address

[tricknotes]

Summary

The dev_server host option currently serves three purposes at once: the address the development server binds to, the address Rails connects to it on, and the origin the browser loads the application's assets from.

In a container those purposes conflict. The server must bind to 0.0.0.0 to be reachable through the container's published port, but a page then refers to its assets as http://0.0.0.0:4200/..., and browsers refuse to connect to 0.0.0.0 (Chrome blocks it under Local Network Access), so every asset request fails. Verified against a real application running under Docker Compose, with the browser on the host.

This PR splits the three purposes:

• Add an origin option to dev_server, naming the browser-facing origin independently of host (e.g. dev_server: { host: "0.0.0.0", port: 4200, origin: "http://localhost:4200" }). A trailing slash is stripped. It defaults to http://<host>:<port>, as before.
• DevServer#origin honors it, which covers both the index.html rewriting in Deploy::DevServer and the startup tags emitted by ember-cli-rails-assets 0.9.0 (the helper reads dev_server.origin), so no change is needed on the assets side.
• Rails' own connections to the development server (request / listening?) now use the bind address instead of the origin, with 0.0.0.0 mapped to the loopback interface — the unspecified address asks the server to listen on every interface, but is not an address to connect to.

Also documents the container setup in the README and UPGRADING, and adds a CHANGELOG entry under the unreleased section.

Verified with the setup above (host: "0.0.0.0", port: 4200, published as 4200:4200, origin: "http://localhost:4200"): assets load and HMR works.

Notes

• Based on dev-server-asset-helpers (Document asset helpers serving from the development server #654), since the assets-helper path is one of the consumers of dev_server.origin.