## Summary of changes
Added a mechanism by which an aspect or aspect class can define a
minimum native version in order to be applied.

## Reason for change
Some aspects defined under new features (like aspects for struct
methods, or aspects with generics) can break old native implementations,
so, we need a way to avoid those to be sent or applied.

## Implementation details
Created `FromVersionAttribute` versions of all Aspect attributes. These
inherit from the original attribute adding a **minimum version of the
native library** from which the aspect will be applied. This version is
then added in the end of the aspect line, in a way that makes old native
tracers ignore those lines, as it breaks the old specification.
For new tracers who are able to read that version info, a version
comparison will determine if that line is accepted or dumped, allowing
us to fine tune the aspects set applied.

This aspect attribute which states that this aspect will be only applied
if a native tracer with version `3.2.0` or bigger is found
`[AspectMethodReplaceFromVersion("3.2.0",
"System.String::Concat(System.Collections.Generic.IEnumerable)")]`
will generate this aspect line

`[AspectMethodReplace(\"System.String::Concat(System.Collections.Generic.IEnumerable)\",\"\",[0],[False],[None],Default,[]);V3.2.0]
Concat(System.Collections.Generic.IEnumerable)`

Notice that the version goes in the end, and that's because old tracers
while parsing the line were looking for the text `)] `
This will make old unprepared tracers to automatically ditch the line,
whereas the new one implemented from this PR, will be able to retrieve,
parse and decide what to do with that version info.

## Test coverage
Source generator tests have been written to ensure the correct use and
aspect generation of version flavor aspect attributes.

## Other details


<!-- ⚠️ Note: where possible, please obtain 2 approvals prior to
merging. Unless CODEOWNERS specifies otherwise, for external teams it is
typically best to have one review from a team member, and one review
from apm-dotnet. Trivial changes do not require 2 reviews. -->

## Summary of changes
Added a mechanism by which an aspect or aspect class can define a
minimum native version in order to be applied.

## Reason for change
Some aspects defined under new features (like aspects for struct
methods, or aspects with generics) can break old native implementations,
so, we need a way to avoid those to be sent or applied.

## Implementation details
Created `FromVersionAttribute` versions of all Aspect attributes. These
inherit from the original attribute adding a **minimum version of the
native library** from which the aspect will be applied. This version is
then added in the end of the aspect line, in a way that makes old native
tracers ignore those lines, as it breaks the old specification. For new
tracers who are able to read that version info, a version comparison
will determine if that line is accepted or dumped, allowing us to fine
tune the aspects set applied.

This aspect attribute which states that this aspect will be only applied
if a native tracer with version `3.2.0` or bigger is found
`[AspectMethodReplaceFromVersion("3.2.0",
"System.String::Concat(System.Collections.Generic.IEnumerable)")]` will
generate this aspect line


`[AspectMethodReplace(\"System.String::Concat(System.Collections.Generic.IEnumerable)\",\"\",[0],[False],[None],Default,[]);V3.2.0]
Concat(System.Collections.Generic.IEnumerable)`

Notice that the version goes in the end, and that's because old tracers
while parsing the line were looking for the text `)] ` This will make
old unprepared tracers to automatically ditch the line, whereas the new
one implemented from this PR, will be able to retrieve, parse and decide
what to do with that version info.

## Test coverage
Source generator tests have been written to ensure the correct use and
aspect generation of version flavor aspect attributes.

## Other details


<!-- ⚠️ Note: where possible, please obtain 2 approvals prior to
merging. Unless CODEOWNERS specifies otherwise, for external teams it is
typically best to have one review from a team member, and one review
from apm-dotnet. Trivial changes do not require 2 reviews. -->

## Summary of changes

## Reason for change

## Implementation details

## Test coverage

## Other details
<!-- Fixes #{issue} -->

<!-- ⚠️ Note: where possible, please obtain 2 approvals prior to
merging. Unless CODEOWNERS specifies otherwise, for external teams it is
typically best to have one review from a team member, and one review
from apm-dotnet. Trivial changes do not require 2 reviews. -->