Don't treat parameters with an explicit index as named

[simolus3]

Unlike most of the other libraries we use, better-sqlite3 supports binding parameters by name, extracting values from an object. The way the current implementation works is that named parameters in fact have to be given by name and can't be given as an array. For instance, the query SELECT :name can't be executed with execute(['Simon']), one has to use execute({name: 'Simon'}).

Unfortunately, this requirement is also applied to variables that aren't named at all! The implementation just used to check for sqlite3_bind_parameter_name returning NULL, but that's not the case for parameters with an explicit index (e.g. SELECT ?1).
As a consequence, better-sqlite3 behaves quite weirdly here and wouldn't allow that statement to be executed with execute(['Simon']), one would have to use {[1]: 'Simon'} I suppose. This behavior is different from our other SDKs, which is obviously quite bad.

This PR fixes the internal check to treat ?NNN variables as non-named. This should mostly keep backwards compatibility while also ensuring that we can use these parameters with better-sqlite3. There's still a problem if users other named variables (SELECT :name) because our Node SDK will pass an array to better-sqlite3 which won't work.

One could argue that this approach of binding named parameters is fundamentally flawed to begin with (because in SQLite, named parameters also have an associated index). So passing an array to bind named parameters should be allowed, but it breaks better-sqlite3. I didn't want to do that change right now because I'd then have to also fix a lot of tests. But it might be worth ripping out all special checks for named parameters entirely to restore