Code clean up around TryWriteBigEndian/TryWriteLittleEndian

[EgorBo]

Contributes to #94941

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-numerics
See info in area-owners.md if you want to be subscribed.

[xtqqczze]

I wonder whether we could refactor so that the primitive types have internal methods for the implementation, e.g.:

namespace System.Buffers.Binary
{
    public static partial class BinaryPrimitives
    {
        public static void WriteDoubleBigEndian(Span<byte> destination, double value) => value.WriteBigEndian(destination);
    }
}

namespace System
{
    public readonly struct Double
    {
        [MethodImpl(MethodImplOptions.AggressiveInlining)]
        internal void WriteBigEndian(Span<byte> destination)
        {
            if (BitConverter.IsLittleEndian)
            {
                long tmp = BinaryPrimitives.ReverseEndianness(BitConverter.DoubleToInt64Bits(m_value));
                MemoryMarshal.Write(destination, in tmp);
            }
            else
            {
                MemoryMarshal.Write(destination, in m_value);
            }
        }
    }
}

[EgorBo]

I wonder whether we could refactor so that the primitive types have internal methods for the implementation, e.g.:

Not sure this improves anything to be honest. The main motivation behind this change is to remove unsafe code (in this case, duplicated unsafe code).

[MichalPetryka]

@MihuBot

[tannergooding]

Does this one get optimized correctly today?

The perf of Random is fairly sensitive and I believe at the time it wasn't well handled.

[EgorBo]

The codegen seesm to be the same - I've checked. We might want to make various helpers like this as "zero budget" for inliner if we hit any issues because of that

[tannergooding]

sounds good; just wanted to confirm that it was getting handled right since its a slightly different change than all the others in the PR