Properly expose "includes" to different installers

Each installer is trying to do the minimal idiomatic thing for its "target audience", and that means a very inconsistent experience around "includes". Some of these are fundamental limitations, others not so much. Probably there should be some kind of setting that says "this dir structure is important and I need installers to respect it".

## Archives ✅

Archives (tarballs/zips) faithfully implement includes, as the entire feature is basically for them. Includes are placed in the logical root dir, alongside all the binaries (if a dir is included, the dir is in the root and its subdir structure is otherwise preserved).

## Homebrew 🥇

Homebrew doesn't respect the same structure of the archive, but instead respects standard conventions for homebrew packages:

* binaries go in the location homebrew wants them to go
* "docs" (README, LICENSE, CHANGELOG) go in the location homebrew wants
* everything else goes into the "share" directory

## MSI 😬

MSI doesn't really respect anything, and actually inverts the directory structure a bit.

* binaries go in a "bin/" subdir of the selected install dir
* if an autogenerated License.rtf exists, it's placed in the root of the install dir

Some additional upstream work in cargo-wix would be required to teach it about extra files in the embed (WiX is *very* pedantic about specifying included files, iirc).

## NPM 🤷‍♀️

Binaries are unpacked with the binary-install library, other includes completely ignored. I'm unclear what things can/should be done here.

## Shell/Powershell 🤷‍♀️

Binaries are unpacked, other includes completely ignored.

This story is a bit more complicated because shell/powershell actually respects install-path, and the default install-path is `CARGO_HOME`, which is just a directory full of unrelated binaries. It wouldn't be correct or appropriate to unpack other random assets into that location. However if install-path is something like `~/.my-app` or `$MY_APP_VAR`, it's more reasonable to allow the full structure to be unpacked.

Start by comparing the Archives, Homebrew, MSI, NPM, and Shell/PowerShell installer behavior described here, then inspect the cargo-wix and binary-install constraints. Define how an opt-in setting should interact with install-path and CARGO_HOME, and clarify expected include behavior for each installer before implementation.

Written by the indexing model from the issue text.