* Switch repo to use native AzDO container support
This is a major refactor of the YAML used by the installer repo. The goal is to utilize the native container support that AzDO provides, rather than building containers on the fly and issuing commands using custom infrastructure. To do this, the YAML requires a bit of a refactor. The matrix strategy approach used by the repo to build a ton of different OS's does not work with containers, because a matrix strategy only changes the variables available to each build command. It cannot change the AzDO host environment. In order to resolve this, I refactored build.yml to take and use optional container names. In the process of doing this, I discovered a number of other things about the old YAML that just happened to 'accidentally' work and fixed them or did general cleanup. Including:
- This construct, used in build.yml, does not work as you might expect. If the parameter is not declared as a boolean (or not declared at all), this evaluates to "does this parameter exist", not "is it true":
```
${{ if parameters.pgoInstrument }}:
```
- I fully specified all the parameters and their types to avoid issues in the future.
- Build pool selection was moved to build.yml
- Removed some unused parameters.
- There was a **very** subtle indentation change here: 762d2966ee/.vsts-ci.yml (L275-L281). This meant that this leg ran in both PR and official builds. I have no idea whether this was the intention or not, but I kept it this way and reorganized the file.
**One change of note:** One of the upsides of the original matrix based approach is that job dependencies are simple. The jobs generated by the matrix are referred to in `dependsOn` lists only by the original job that contains the matrix. That keeps the dependsOn list small even if the number of jobs generated is large. Installer has a large set of independently addressable jobs now. Normally, we would solve this by using the arcade jobs template. The jobs template takes a set of jobs and automatically adds dependsOn for the publishing jobs. BUT, AzDO does not allow templates to be passed as parameters to other templates. This would mean that you couldn't use the build.yml template in conjunction with the jobs template and would have to list all the installer jobs as dependencies. This list would be hard to keep up to date. To avoid this, I used a new feature of publishing (`publishAssetsImmediately`) which uses the Publish To Build Asset Registry job to do the actual publishing call, and put it in a separate phase, then eliminated the post-build.yml call. This means that the publishing stage depends on all jobs in the build stage, and does not need to address them individually. Eliminating the post-build.yml stage may seem odd, but this is what actually happens when `publishAssetsImmediately` is set to true anyway.
8dc41755cb