vector-search: avoid unaligned reads

[sivukhin]

Now vector search can produce unaligned reads because node metadata is not aligned to word boundary (it has size of 10 bytes) and if we will store F32/F64 vectors in the node - they will be be accessed with half-word offset.

You can test the issue like this:

$> make CC=clang CFLAGS='-fsanitize=alignment' testfixture
$> ./testfixture test/libsql_vector*
...
vector-f32-compress-bf16...sqlite3.c:212025:39: runtime error: load of misaligned address 0x5d89bb2b0b1a for type 'float', which requires 4 byte alignment
0x5d89bb2b0b1a: note: pointer points here
...

This can create real trouble on some architectures. For example, seems like Cortex-A series of ARM CPU supports unaligned reads but this capability must be enabled explicitly (see https://developer.arm.com/documentation/den0013/d/Porting/Alignment)

For the Cortex-A series of processors, unaligned accesses are supported, although you must enable this by setting the U bit in the CP15:SCTL register, indicating that unaligned accesses are permitted.

The complication in the fix lying in the fact that we reuse memory from sqlite blobs a lot in the vector search code and quite often instead of additional allocation we just initialize vector from blob memory (see vectorInitStatic).

So, due to the complication, this PR attack the problem from format perspective and align metadata to double-word boundary - making read to have proper alignment.

Note, that PR introduce V3 on-disk binary format with the fix and unaligned reads will be fixed only for newly created indices (old ones will continue to work as it is - but will have potential unaligned reads issue)

[haaawk]

LGTM modulo my misunderstanding of the comment