Investigate options for shipping EDOT SDK and auto instrumentation separately as with vanilla OTel

[stevejgordon]

The 1.10 of the OTel SDK has shipped, but auto instrumentation is still on 1.9, which references and pulls in the 1.9 SDK.

This introduces challenges for EDOT, where we might need to bump to the latest SDK without breaking our auto instrumentation release.

To avoid issues when the auto instrumentation ships behind the main SDK version, we may need to be able to build against different SDK versions based on a MsBuild flag. That way, we can, for example, ship EDOT based on SDK 1.10 while also being able to deploy an auto instrumentation zip bundling an older build of EDOT and, therefore, the SDK. This isn't an ideal solution either since our artefacts may not align for each release which is confusing.

[stevejgordon]

The current plan will be to update our release process to independently release the core SDK and the auto-instrumentation artefacts. We will update minver, per https://github.com/adamralph/minver?tab=readme-ov-file#can-i-version-multiple-projects-in-a-single-repository-independently and update the build script to handle independent releases, which we will title separately. This unblocks us from releasing SDK features when the auto-instrumentation release is delayed.