unlock installer strategies

There are two major strategies for installers, "fetching" and "bundling". Currently each kind of installer is hardcoded to a strategy, but it would be cool if we could make that configurable (where it makes sense):

Glossary:

* ✅ implemented
* ❔possible
* ❌ probably wouldn't make sense

| | Fetching | Bundling |
|------------: | :----------: | :-------: |
| shell | ✅ | ❌ (1) |
| powershell | ✅ | ❌ (1) |
| npm | ✅ | ❔(2) |
| homebrew | ✅ | ❌ (3) |
| msi | ❔(4) | ✅ |

Notes:

1. shell/powershell installers that bundle binaries are a horrifying concept that should not be considered
2. npm packages that bundle binaries could make sense, I think people do it, although they use a complicated system where they have one package for each platform, and then a meta-package that depends on them all and picks the right one at install-time
3. homebrew installers cannot bundle binaries, but they can be from-source (not currently interested in exploring that space)
4. fetching msi's make perfect sense, we just defaulted to bundling as more conventional and friendly to enterprises

No files, tests, or entry points are named. First locate where installer strategies are selected, then determine the configuration and scope for each strategy in the issue's fetching and bundling matrix; done means supported combinations are configurable without enabling the combinations marked as unsupported.

Written by the indexing model from the issue text.