…7884)

## Summary of changes

- Fixes "incorrect" generated code from `TagsList`
  - Removes significant additional overhead during serialization
- "Fix" vendored System.Buffers code to avoid the same issue

## Reason for change

The current generated code for `TagsList` produces something like this:

```csharp
private static ReadOnlySpan<byte> DbTypeBytes => new byte[] { 167, 100, 98, 46, 116, 121, 112, 101 };
```

This _looks_ like it's allocating a new `byte[]` with every invocation,
but the compiler actually optimizes this away to be completely
zero-allocation, by embedding the array as part of the dll, and then
simply returning a `ReadOnlySpan` wrapper pointing to this fixed data.
You can see this if you look at the generated IL:

```
  .method private hidebysig static specialname valuetype [System.Runtime]System.ReadOnlySpan`1<unsigned int8>
    get_DbTypeBytes() cil managed
  {
    .maxstack 8

    // [20 58 - 20 109]
    IL_0000: ldsflda      int64 '<PrivateImplementationDetails>'::A06A154BE3B860D0B56FA96C93523B732045BA0BCE2FFD4769109575CF1953BF
    IL_0005: ldc.i4.8
    IL_0006: newobj       instance void valuetype [System.Runtime]System.ReadOnlySpan`1<unsigned int8>::.ctor(void*, int32)
    IL_000b: ret

  } // end of method SqlTags::get_DbTypeBytes
```

However, in .NET Framework, even though we have vendored
`ReadOnlySpan<T>` so we can get some of the benefits (mostly cleaner
code), we _don't_ get these benefits. Which means that the above code
_does_ generate a new array with every invocation:

```
  .method private hidebysig static specialname valuetype Datadog.Trace.VendoredMicrosoftCode.System.ReadOnlySpan`1<unsigned int8>
    get_DbTypeBytes() cil managed
  {
    .maxstack 8

    // [20 58 - 20 109]
    IL_0000: ldc.i4.8
    IL_0001: newarr       [netstandard]System.Byte
    IL_0006: dup
    IL_0007: ldtoken      field int64 '<PrivateImplementationDetails>'::A06A154BE3B860D0B56FA96C93523B732045BA0BCE2FFD4769109575CF1953BF
    IL_000c: call         void [netstandard]System.Runtime.CompilerServices.RuntimeHelpers::InitializeArray(class [netstandard]System.Array, valuetype [netstandard]System.RuntimeFieldHandle)
    IL_0011: call         valuetype Datadog.Trace.VendoredMicrosoftCode.System.ReadOnlySpan`1<!0/*unsigned int8*/> valuetype Datadog.Trace.VendoredMicrosoftCode.System.ReadOnlySpan`1<unsigned int8>::op_Implicit(!0/*unsigned int8*/[])
    IL_0016: ret

  } // end of method SqlTags::get_DbTypeBytes
```

This is... Bad 😅 And it explains the _significant_ serialization
overhead identified in #7882 for .NET Framework. I also confirmed this
applies to all <.NET Core 3.1 too (because we compile for .NET Standard)


| Method | Runtime | Mean | Allocated | Alloc Ratio |
| -------------------------- | -------------------- | -------: |
--------: | ----------: |
| WriteEnrichedTraces_Before | .NET 6.0 | 488.9 us | 110 B | 0.001 |
| WriteEnrichedTraces_Before | .NET Framework 4.7.2 | 703.3 us | 112537
B | 1.000 |
| | | | | |
| WriteEnrichedTraces_After | .NET 6.0 | 469.1 us | 105 B | 0.50 |
| WriteEnrichedTraces_After | .NET Framework 4.7.2 | 703.4 us | 208 B |
1.00 |

## Implementation details

The fix is to just do what we were doing before #5298 introduced this
regression 😄 i.e. generate code like this:

```csharp
#if NETCOREAPP
    private static ReadOnlySpan<byte> DbTypeBytes => new byte[] { 167, 100, 98, 46, 116, 121, 112, 101 };
#else
    private static readonly byte[] DbTypeBytes = new byte[] { 167, 100, 98, 46, 116, 121, 112, 101 
#endif
```

## Test coverage

This is all covered by existing tests, and the new benchmark shows the
improvment

## Other details

I found a couple of other places in the vendored code that has the same
issue, and fixed them directly in the code. However, this is not ideal,
as if we re-vendor, we'll clobber these updates, so we'll need to update
the vendoring code too

…7884)

## Summary of changes

- Fixes "incorrect" generated code from `TagsList`
  - Removes significant additional overhead during serialization
- "Fix" vendored System.Buffers code to avoid the same issue

## Reason for change

The current generated code for `TagsList` produces something like this:

```csharp
private static ReadOnlySpan<byte> DbTypeBytes => new byte[] { 167, 100, 98, 46, 116, 121, 112, 101 };
```

This _looks_ like it's allocating a new `byte[]` with every invocation,
but the compiler actually optimizes this away to be completely
zero-allocation, by embedding the array as part of the dll, and then
simply returning a `ReadOnlySpan` wrapper pointing to this fixed data.
You can see this if you look at the generated IL:

```
  .method private hidebysig static specialname valuetype [System.Runtime]System.ReadOnlySpan`1<unsigned int8>
    get_DbTypeBytes() cil managed
  {
    .maxstack 8

    // [20 58 - 20 109]
    IL_0000: ldsflda      int64 '<PrivateImplementationDetails>'::A06A154BE3B860D0B56FA96C93523B732045BA0BCE2FFD4769109575CF1953BF
    IL_0005: ldc.i4.8
    IL_0006: newobj       instance void valuetype [System.Runtime]System.ReadOnlySpan`1<unsigned int8>::.ctor(void*, int32)
    IL_000b: ret

  } // end of method SqlTags::get_DbTypeBytes
```

However, in .NET Framework, even though we have vendored
`ReadOnlySpan<T>` so we can get some of the benefits (mostly cleaner
code), we _don't_ get these benefits. Which means that the above code
_does_ generate a new array with every invocation:

```
  .method private hidebysig static specialname valuetype Datadog.Trace.VendoredMicrosoftCode.System.ReadOnlySpan`1<unsigned int8>
    get_DbTypeBytes() cil managed
  {
    .maxstack 8

    // [20 58 - 20 109]
    IL_0000: ldc.i4.8
    IL_0001: newarr       [netstandard]System.Byte
    IL_0006: dup
    IL_0007: ldtoken      field int64 '<PrivateImplementationDetails>'::A06A154BE3B860D0B56FA96C93523B732045BA0BCE2FFD4769109575CF1953BF
    IL_000c: call         void [netstandard]System.Runtime.CompilerServices.RuntimeHelpers::InitializeArray(class [netstandard]System.Array, valuetype [netstandard]System.RuntimeFieldHandle)
    IL_0011: call         valuetype Datadog.Trace.VendoredMicrosoftCode.System.ReadOnlySpan`1<!0/*unsigned int8*/> valuetype Datadog.Trace.VendoredMicrosoftCode.System.ReadOnlySpan`1<unsigned int8>::op_Implicit(!0/*unsigned int8*/[])
    IL_0016: ret

  } // end of method SqlTags::get_DbTypeBytes
```

This is... Bad 😅 And it explains the _significant_ serialization
overhead identified in #7882 for .NET Framework. I also confirmed this
applies to all <.NET Core 3.1 too (because we compile for .NET Standard)


| Method | Runtime | Mean | Allocated | Alloc Ratio |
| -------------------------- | -------------------- | -------: |
--------: | ----------: |
| WriteEnrichedTraces_Before | .NET 6.0 | 488.9 us | 110 B | 0.001 |
| WriteEnrichedTraces_Before | .NET Framework 4.7.2 | 703.3 us | 112537
B | 1.000 |
| | | | | |
| WriteEnrichedTraces_After | .NET 6.0 | 469.1 us | 105 B | 0.50 |
| WriteEnrichedTraces_After | .NET Framework 4.7.2 | 703.4 us | 208 B |
1.00 |

## Implementation details

The fix is to just do what we were doing before #5298 introduced this
regression 😄 i.e. generate code like this:

```csharp
#if NETCOREAPP
    private static ReadOnlySpan<byte> DbTypeBytes => new byte[] { 167, 100, 98, 46, 116, 121, 112, 101 };
#else
    private static readonly byte[] DbTypeBytes = new byte[] { 167, 100, 98, 46, 116, 121, 112, 101 
#endif
```

## Test coverage

This is all covered by existing tests, and the new benchmark shows the
improvment

## Other details

I found a couple of other places in the vendored code that has the same
issue, and fixed them directly in the code. However, this is not ideal,
as if we re-vendor, we'll clobber these updates, so we'll need to update
the vendoring code too