Handle zero-length Span inputs for sqlite3_bind_text*

[nil4]

Same as sqlite3_bind_blob, the SQLite C APIs sqlite3_bind_text* require the data pointer argument to be non-null to actually accept zero-length input. Otherwise, when a null data pointer is passed, the explicit length is ignored and a SQLITE_NULL value is bound instead.

This PR updates sqlite3_bind_text and sqlite3_bind_text16 to handle zero-length ReadOnlySpans, by substituting a valid pointer for the zero-length case.

The generated sqlite3_bind_blob code already handled this scenario by allocating a new byte[] for each call e.g. at:

SQLitePCL.raw/src/providers/provider.tt

Lines 1586 to 1595 in 9c66b4f

	// passing a zero-length blob to sqlite3_bind_blob() requires
	// a non-null pointer, even though conceptually, that pointer
	// point to zero things, ie nothing.
	var ba_fake = new byte[] { 42 };
	ReadOnlySpan<byte> span_fake = ba_fake;
	fixed (byte* p_fake = span_fake)
	{
	return NativeMethods.sqlite3_bind_blob(stm, paramIndex, p_fake, 0, new IntPtr(-1));
	}

This PR proposes a potentially lower-overhead solution (passing the address of a local) for both sqlite3_bind_text* and sqlite3_bind_blob, as suggested by Span<T> usage Rule #9:

In the previous example, pbData can be null if, for example, the input span is empty. If the exported method absolutely requires that pbData be non-null, even if cbData is 0, the method can be implemented as follows

These changes address the sqlite3_bind_text* functions behavior when called with empty ReadOnlySpan.

Fixes #557

[ericsink]

I made a code change similar to this PR, but keeping the explicit checks for Length == 0. Thanks!