Document-relative m-frame and content addressing (#72)

[MarcusLongmuir]

Currently src attributes are interpreted as being relative to the page that the MML content has been loaded into. (e.g. an m-image with src="/foo.png" loaded on page localhost:8080 would result in requesting http://localhost:8080/foo.png)

If the m-image was an element of a remote document (e.g. an m-frame loaded from ws://example.com/) then src="/foo.png" should instead resolve to http://example.com/foo.png.

This PR resolves #72 by introducing addresses for the RemoteDocument element and then using those as the location to resolve relative paths. This means that content addressed from within an m-frame will be relative to the address of the m-frame.

This also works for m-frames by using relative WebSocket addresses in the form ws:///foo from an origin of http://example.com/bar/baz. The WebSocket will resolve to ws://example.com/foo.

---

What kind of changes does your PR introduce? (check at least one)

• Feature

Does your PR introduce a breaking change? (check one)

• Yes

If yes, please describe its impact and migration path for existing applications:

(It's unlikely that someone is using this behaviour intentionally)

If a remote document is loaded from an origin and then references relative paths that are assumed to be relative to the page that has loaded this document then the urls would now resolve relative to the remote document. The origin-relative content would have to be specified absolutely to retain the same behaviour.

Does your PR fulfil the following requirements?

• All tests are passing
• The title references the corresponding issue # (if relevant)