Api host proxy mixin

[aars]

This PR includes:

• Better generated url from blueprint (uses API_HOST as well as API_PATH).
• Sane default for adapter url through computed property (when not using generated url).
  • simplifies dummy app using this default.
• Adds AdapterApiHostProxyMixin to keep example usage of API_HOST_PROXY in addon.
  • Removes confusing fetchUrl implementation from adapter blueprint
    • url = url.replace(proxy, host); !???? Was that supposed to be like that?

I've tried setting up the tests in an appropriate tests/unit/mixins file but I failed to get it running (missing owner, container, registry, etc). Test is added to adapter's unit test.

[pixelhandler]

@aars not sure if I mentioned it to you yet, I often use a test repo for manually testing too, see - https://github.com/pixelhandler/jr-test I think the dummy app works in this repo for testing, but needed an app that is actually consuming the addon (aside from dummy app behavior). If you have time would you consider some updates on the jr-test repo as well?

[pixelhandler]

@aars thanks for adding this as a mixin :)

[aars]

My pleasure. When I find the time I'll look through all the docs. Those needs some touching up I reckon.

[pixelhandler]

@aars would you mind making one change to keep the config import in the blueprint?

import config from '../config/environment';

[aars]

@pixelhandler I messed up with the config import statement yeah.

When the blueprint fix/tests get merged we can add some more specific blueprint tests to catch this.

[aars]

@pixelhandler One "major" change in here is the reversal of API_HOST and API_HOST_PROXY. previously the proxy value got replaced by the host value... which... was very confusing to me at least, especially since API_HOST was set to '/' in all examples. Which isn't really a host.
(Ok I get it now.. '/' would mean "the same host the frontend runs on". I'll add a comment about this. I can probably improve the api-host-proxy-mixin example as well, something something trailing slashes.)

I thought it made more sense to define the API_HOST_PROXY as the actual proxy we're using to connect to API_HOST. So I did. But I can't really assess the impact of this change. I wonder how most users use this lib, and if they kept the original example and edited it to their needs, and thus, if this change will break their stuff. If we decide to keep this change it would be very worth updating docs and mentioning this in changelog before making a new release.