Use Span for SFML.Net API

[Marioalexsan]

Making this draft as a starting point for Span-related changes. This might also be a good place to look over some memory allocations happening in the library. The idea is as follows:

• Use System.Memory to gain access to Span, which is usable in .NET Standard 2.0
• Replace T[] with Span in input parameters where possible - this is a trivial change that just allows slicing
• Replace T[] returns with Span where possible (i.e. when we want to just give a view into memory) - this reduces the number of allocations and solves some anti-patterns like Image.Pixels

In some cases it's harder to use Span due to lack of methods that are available only in .NET Core. One such example is StreamAdaptor where you cannot read into a Span.

I'm also thinking we could use stackalloc for places that use patterns like byte[] titleAsUtf32 = Encoding.UTF32.GetBytes(title + '\0'). There is an overload for GetBytes that can work with pointers, which could be used together with stackalloc for small-sized strings to avoid allocating small temporary strings on the heap.

[DemoXinMC]

Do we want to FORCE using slices? This removes the ability to specify offsets and lengths during Draw()

[Marioalexsan]

The way I see it, the second overload is just a span-like version of the first one, so users could just do vertices.Slice(0, 3) if they want to do offsets and lengths.

[DemoXinMC]

I'm personally fine with the changes to ptr vs PixelPtr everywhere, but that is purely semantics and it might be beneficial to actually create some coding style rules for the project that we don't currently have and this would be relevant to that discussion.

[DemoXinMC]

Same as RenderTexture

[DemoXinMC]

While I know that UTF32 is going to yield 4 bytes per char, does it make more sense to use sizeof() for clarity on this and the other uses of UTF*.GetString()?

[DemoXinMC]

Is it reasonable to add a set method for Pixels?

[DemoXinMC]

Is there not a way that we can use AddRange() with Span? Also, Audio is likely going to benefit from a significant rework, but that's beyond the scope of this draft.

[Marioalexsan]

There is no such overload for AddRange() if I remember correctly.

[DemoXinMC]

Since we .NET doesn't own the memory for samples, should we be handling this this way? Our Span could be invalidated if CSFML moves things IIRC

[charleyah]

This will be safe for the lifetime of the SoundBuffer object instance for as long as all public members on SoundBuffer class don't produce iterator invalidation on the underlying std::vector containing the samples on sf::SoundBuffer (m_samples).

[charleyah]

Was there any consideration to use ReadOnlySpan<T> for the cases where SFML functions are reading from a span argument and not writing back to a caller provided buffer? At a glance that looks like the majority of cases.

Properties like Image.Pixels and SoundBuffer.Samples still make sense as Span<T> to allow callers to modify underlying data.

[Marioalexsan]

@charleyah I haven't given it much thought initially, but yeah, we could use read-only spans in those places I think. I'd prefer to redo this PR after implementing all of the SFML.Net 3 changes though.