Move portion of the upgrade logic into the downloaded release

[joshdover]

Today, the entire agent upgrade process is executed by the old version being upgraded from. This has some limitations because it requires that the old release has enough information to be able to install the new version, which can slow down our ability to make changes to the install format, location, and procedure.

Some recent examples of how this problem presented itself:

• We had to revert Bundle elastic-agent.app for MacOS, needed to be able to enable the … #714 because older versions didn't know how to update the symlink to the new binary location
• We had to add extra migration code in the 8.3 release to handle the new secret storage: Fix Agent upgrade 8.2->8.3 #578

We could mitigate this by moving a portion of the upgrade logic to a script contained in the tarball that is being upgraded to. This could lead to a procedure like:

• Agent 9.0 downloads and unpacks 9.1 to a temporary directory
• Agent 9.0 calls /tmp/path/to/9.1/upgrade.sh
• upgrade.sh takes care of copying files to appropriate location, updating symlinks, and executing any other required logic for new features introduced since 9.0

One challenge with adding and relying on this is that we currently support upgrading from any 8.x version up to any other, so we wouldn't be able to rely on this until the next major version, and even then we'd only be able to rely on it if we require users upgrade to 8.last before upgrading to 9.x. Likely, the sooner we get something like this in the sooner we can take advantage of it.

cc @aleksmaus

[cmacknz]

Can we close this, given this is essentially the approach taken in #1392 already?