Support domain based language negotiation

I think we could probably do this all in the Drush commands, just get all the configured domains and hit every static path with every domain. Would be pretty slow but that's the only way to guarantee that absolute paths are correct for every export.

Copying from #3022653: Multilingual site with domain negotation:

Tried it out on a multilingual project with 4 languages and domain-based negotiation.

Note: I used the UI because I'm not yet using drush 9.

It seems it doesn't like that very much and gets pretty confused. What happens is that in the html folder, there is a "http:" folder, and then below, there is a file/folder for each language domain. in my local instance, it looks like this:

example.fr (folder)
example.it (folder)
example.local (german, default, this is a file...)

I also have tons of warnings like this:

Warning: file_put_contents(../html/http://example.local/taxonomy/term/85/index.html): failed to open stream: No such file or directory

(because example.local is a file)

Notice: Undefined index: path in Drupal\tome_static\StaticGenerator->filterInvokePaths() (Zeile 241 in ../web/modules/contrib/tome/modules/tome_static/src/StaticGenerator.php) #0

Another thing I noticed is that it might also conflict with the canonical redirect feature of the redirect module, because in another language, it created example.fr/home/index.html, which is nothing but a redirect to example.fr.

Also, because I'm too lazy to create multiple issues: I noticed that the UI fails hard in Drupal 8.5 because the BatchBuilder only exists in Drupal 8.6, so it should have a version-dependency on that :)

Here's a fix for the "http:// in the path" bug mentioned in #5. Apparently Url objects can be assembled as absolute even when you explicitly set the absolute option to FALSE - reading through core a bit showed me that the absolute flag is only for making relative paths absolute. Because of this, when using domain based language negotiation, some paths collected early in Tome's process included absolute paths.

For the canonical redirect issue, I'm not sure I understand the problem. @Berdir, if you're following this issue, care to comment?

There's a performance problem here as well - with the last patch every translation of every entity will be processed for each domain. At first I thought that a good solution would be to only process entity translations for the current domain's language if domain negotiation is used, but that might be too aggressive.

For example, if you have one translation of an entity with no path, it is available on all domains at its canonical path (i.e. /node/1). If you have one translation with a path, that path 404s on other domains.

Here's a rough patch that excludes paths for other domains, but doesn't solve the edge case yet.

Added test coverage. I think it's OK if we just document this behavior and don't support the edge case from #7.

Let's get this in as-is - it's better than no support at all and the edge case has an easy workaround (set an alias).