Move CowData find, rfind and count to Span

[Ivorforce]

The idea of this PR is to establish span_algorithms.h, where we can put algorithms that run on spans.

There are 3 that are currently defined in CowData, which could be better defined on Span. In this way, people owning a LocalVector (or perhaps even something else, like Array) could use e.g. spans::find to find data in the container without re-implementing the algorithm. This is especially important because the algorithms are optimized for speed, while new implementations probably won't be.
In addition, the new implementations are substantially faster (same improvement / reason as #102059).

If we agree to go ahead with this, we can move a lot more functions to the spans namespace, to start deduplicating Vector, LocalVector and String code.

Helps address godotengine/godot-proposals#5144

[Repiteo]

I really like the core idea, but I'm not sure why we're opting for a separate header/namespace over methods within Span itself. Everything so far uses Span as the first argument, and based off the name I imagine that'll be the case for the overwhelming majority of functions, so separating them feels like unnecessary bloat. Even if certain functions don't need to be scoped under Span, the convention is generally to have accompanying classes/functions within the same file (Variant being the only real exception thanks to its insane size), so that code should all be in span.h regardless.

[Ivorforce]

I really like the core idea, but I'm not sure why we're opting for a separate header/namespace over methods within Span itself. Everything so far uses Span as the first argument, and based off the name I imagine that'll be the case for the overwhelming majority of functions, so separating them feels like unnecessary bloat. Even if certain functions don't need to be scoped under Span, the convention is generally to have accompanying classes/functions within the same file (Variant being the only real exception thanks to its insane size), so that code should all be in span.h regardless.

Tbh., I also kind of dislike needing the Spans::func(span, ...) instead of just span.func(...). I'd put it all in extension headers if that was possible 😅

The reason I was even considering putting them in a separate header was compile times and decoupling. But perhaps that's premature optimization.

[Repiteo]

No clue how much compile times would be impacted—that's something I think needs more investigation overall—but decoupling is absolutely premature optimization; Span should be interlinked with functions designed explicitly for Span.

[Ivorforce]

Alright, I don't really disagree so I've just moved the functions to Span.
I've also removed the Size template parameter, which in hindsight isn't very useful.

[Repiteo]

Looks great!

[Repiteo]

Thanks!