Own the interpretation of an application's build output

[tricknotes]

Why

The asset helpers in ember-cli-rails-assets read a built application to work out what it boots from:
where its assets live, how index.html refers to them, which name package.json gives it, and whether the build is Vite-based.

This gem runs the build, so it already knows all of that.
The two ended up answering the same question in different ways — this gem detects a Vite build from the configuration file at the application's root, while the helpers looked for a module script in the generated index.html.

The dependency also pointed both ways: this gem depended on the helpers, while the helpers called EmberCli::App without declaring that they needed it, and worked around older releases with respond_to?(:dev_server?).

What

Move the interpretation of a build's output here, behind EmberCli::Embedding, the API for embedding an application into a page of its own.
It wraps an application (EmberCli::Embedding.new(EmberCli["frontend"])) and reports:

• #startup_tags? — whether the application boots from startup tags, as it does when Vite's development server or a Vite build serves it
• #startup_tags(prepend:) — those tags, read from the development server or the build directory, whichever serves the application
• #javascript_assets(prepend:) and #stylesheet_assets(prepend:) — the assets a classic build boots from, with prepend joined onto the ones that point into the build

EmberCli::App gains only #vite?, as which build system an application uses is not specific to embedding it.

The classes behind EmberCli::Embedding are private constants of it, so they can change without breaking anyone:

• AssetMap resolves the references in a classic build's index.html against the files ember build wrote, replacing the helpers' AssetMap, DirectoryAssetMap and Lookup
• StartupTags extracts the boot tags of a Vite build and joins a prefix onto their root-relative URLs
• Url recognizes a URL that resolves outside the build, which both of the above leave alone

Because EmberCli::Embedding chooses between the development server and the build directory itself, callers no longer feature-detect the development server.
Because the readers take prepend, callers no longer decide which URLs it applies to.
It reads the build through what EmberCli::App already exposes, such as #dist_path, so nothing else is added to EmberCli::App or EmberCli::PathSet.

The behaviour the helpers gained in tricknotes/ember-cli-rails-assets#43 and #45 comes along:
an asset the build does not produce (a CDN, a font service) is reported as the document refers to it, a tag carrying no URL is skipped, and a reference resolves by the longest trailing path it shares with the build output, so an addon's nested asset resolves to the file it names.

With this knowledge here, the dependency on ember-cli-rails-assets is dropped, and the helpers declare a dependency on this gem instead.
Bundler refuses to resolve a dependency that points both ways, so this direction has to be the one that survives.
nokogiri moves here for the same reason.

The feature scenario that rendered the helpers in a page of its own now embeds the tags from EmberCli::Embedding instead, without the helpers.
It was the only test booting an application from tags embedded into a page, and the only one doing so for a Vite build, so it keeps the contract covered across the whole build and package manager matrix here, where changes to it are made.
Its page moves from /asset-helpers to /embed: mounting at /embedded would name its redirect route embedded, clashing with the route it names.

Compatibility

An application that renders include_ember_script_tags or include_ember_stylesheet_tags now needs gem "ember-cli-rails-assets" in its own Gemfile, where it used to arrive as a dependency of this gem.
render_ember_app and mount_ember_app are unaffected.

UPGRADING.md carries that, and the constants the helpers no longer expose, under a heading for 1.0.0.
The README no longer claims this gem injects the assets itself.

The version is left to the release commit, as RELEASING.md asks.

Testing

• spec/lib passes, including the EmberCli::Embedding spec, which covers the classes behind it through its public methods and checks that they stay private
• the embedding page renders the config <meta> tag, the stylesheet and modulepreload links, and the module script of a Vite build from EmberCli::Embedding; booting it in a browser is left to CI, as the local Chrome and ChromeDriver disagree on their version
• the split was exercised against a real application, with and without the helpers installed