vector search index key fix

[sivukhin]

Context

Initially, this PR aimed to change behaviour of vector index to prefer use PK over ROWID if both available, but we decided to preserve current vector index behaviour to always prefer ROWID (if any) because it aligned with SQLite native B-Tree indices behaviour.

Still, this PR introduce few useful changes:

1. bUnordered=1 set for vector index in order to prevent SQLite from using vector index in different optimizations
2. vectorIdxKeyGet implemented more carefuly - now it look at the structure of index key and will adapt to what we will decide about index key structure during it's creation (so, we can more easily change behaviour in future if we will need this)
3. vector index shadow table now always define INTEGER PRIMARY KEY in order to preserve rowid (and PK) in dumps

[penberg]

@sivukhin Let's follow normal SQLite indexing semantics. If a table has a rowid, we use it, but if the table was created with WITHOUT ROWID, we use the primary key.

[sivukhin]

@penberg, yes, maybe I overcomplicated it. Initially, I thought that we can't rely on rowid if table with vector index will be replicated with something like cr-sqlite. But actually, if only table will be replicated - then it doesn't matter how we structure our shadow tables - because they will be rebuild (not replicated!) on replicas with their own rowids.

The only thing we will need to fix with rowid is that we will need to preserve it in the dumps.

[penberg]

Right. We do need the PK version of course too because of WITHOUT ROWID, but hopefully easy tweak to the PR.