Test ElasticApmAgent_<Version>.zip on CI

[russcam]

Relates: #1051, #1072

Once the ElasticApmAgent_.zip build is running on CI (#1072), the zip file should be tested to ensure that the generated artifact can auto instrument an ASP.NET Core web application without code changes.

Possible implementation

1. A barebones sample ASP.NET Core application is introduced, as the target application for startup hood testing
2. A build target is added to the scripts F# project with a dependency on the agent-zip target that
   1. unzips the ElasticApmAgent_.zip to a known location
   2. uses docker to run the sample ASP.NET Core with the DOTNET_STARTUP_HOOKS environment variable pointing to the unzipped ElasticApmAgent_ location
3. Collects agent logs from the sample application, or indexed data from Elasticsearch to verify that auto instrumentation is operating correctly.

Investigation

From current investigation, the major version of System.Diagnostics.DiagnosticSource that the agent references must match the version that the web application uses.

The agent subscribes to diagnostic events using DiagnosticListener.AllListeners.Subscribe(...). If the ASP.NET Core application is using System.Diagnostics.DiagnosticSource 4.x, but the APM agent is using System.Diagnostics.DiagnosticSource 5.0.0, the agent will not be able to load the 5.0.0 version of the assembly into AssemblyLoadContext.Default - a FileLoadException is thrown.

An approach to load assemblies with conflicting versions is to create a different AssembyLoadContext and load them into this context. Using a different AssemblyLoadContext to load a 5.0.0 version and a 4.x version of System.Diagnostics.DiagnosticSource works in getting around the version conflict, but since the agent depends on the 5.0.0 version, it will try to subscribe to the DiagnosticListener.AllListeners property of the 5.0.0 version, not the 4.x version that the application is publishing events to. Further, the static DiagnosticListener.AllListeners property is isolated to the context in which it is loaded, so the agent assemblies that subscribe need to be loaded into the same context and be binary compatible, which doesn't seem to be the case if they're compiled against a different version. One way to get around this issue is to reference System.Diagnostics.DiagnosticSource 5.0.0 as a dependency of the application, which works, but we might want to take an alternative approach that doesn't potentially require a user to make changes to their application.