Add a reference constructor to Span. Replace VectorView with Span

[Ivorforce]

• Supersedes Add single-reference constructor to Span, creating a Span of length 1. #103931

This PR adds an implicit conversion from any value reference to a single-element Span, matching a constructor VectorView already had.
With this addition, VectorView can finally be merged into Span.

Span from reference

I finally found a way to satisfyingly support single reference constructors for Span!

My initial implementation was the same as VectorView, implemented in #103931. However, I was not happy with it because it meant that Span could be implicitly created from any value, which made me very uneasy.

Still, after having thought about it for a while, it does make sense for a value to be passed into a function that expects a Span: It just means we want to run the function on the one value. For example, in the future the function could be overloaded with a single value version, automatically optimizing all callers that were previously implicitly converting to Span.

An insight came in the form of implicit type checks. Consider the following code example:

template <typename T>
class Span {
	const T *_ptr = nullptr;
	uint64_t _len = 0;

public:
	 constexpr Span(const T &p_value) :
			_ptr(&p_value), _len(1) {}
};


int main() {
	int i = 0;
	Span<int> span1(i);
	Span<double> span2(i);
	return 0;
}

This compiles fine, but will crash horribly if span2 is ever used, because i is implicitly converted to double, but the temporary is dropped after the call, making the Span immediately garbage.
However, using the following implementation (used in this PR) makes this much safer:

    template <typename T1, typename = std::enable_if_t<std::is_same_v<T1, T>>>
	 constexpr Span(const T1 &p_value) :
			_ptr(&p_value), _len(1) {}

Using this constructor instead, Span<double> span2(i) will statically fail because implicit conversions are not allowed for this constructor.

VectorView to Span

VectorView was initially intended to be used widely across the codebase:

godot/servers/rendering/rendering_device_driver.h

Lines 55 to 56 in 09fcbb8

	// This may one day be used in Godot for interoperability between C arrays, Vector and LocalVector.
	// (See https://github.com/godotengine/godot-proposals/issues/5144.)

Span is this implementation. With the reference constructor out of the way, the two can finally be merged. All that was required was a search-and-replace from VectorView to Span.

Notably, the use of SFINAE requires explicit conversions:

void test(Span<int> span) {
    // ...
}

void main() {
    test(5); // fine
    test(5.0); // impossible
}

In this case it would probably be better to just accept implicit conversions. But I do feel safer with these checks, and we can always generalize if this becomes a problem.

Dangers

Converting from a reference to Span can be considered dangerous. Consider the following code:

Span<int> get_span() {
	int i = 0;
	return i;
}

This will obviously go horribly wrong.

However, this problem already exists in C++ plain:

int& get_int() {
	int i = 0;
	return i;
}

This compiles fine, but will also go horribly wrong.
The main difference is that the compiler will (usually) warn about the latter implementation, but may not understand Span well enough to also warn about the former implementation.

All in all, I think this risk is acceptable, considering C++ is full of memory pitfalls, and this isn't any worse than what C++ has in store for us in other places.