Use a lockfree data structure to store page states

[benjaminwinger]

Note that this only supports safe reads without locks, adding new page states still needs locking, but it would be possible to support updates using atomics.

The ConcurrentVector is optimized in two ways:

1. The initial size is allocated in one chunk, to minimize lookup time for existing elements
2. New elements are added using a linked list of indices, which point to blocks of elements. With an appropriate size, the vast majority of situations should be able to use just one index block.

I currently have the sizes set up so that the access cost of the pageStates structure only increases with every 128GB of new file data. I also played around with increasing the page group size, but settled with using a large index size (256KB) instead as I wasn't sure about the possible side-effects of increasing the page group size.
The ConcurrentVector is also used for the frame group indices stored in the BMFileHandle as I noticed that there could be a data race in getFrameIdx if a new page group is added in another thread (very unlikely, as the frame group index vector is only appended to and not otherwise modified, as other threads would need to resize the vector, claim and then write to the freed memory between when a thread reads the frame group index vector's data pointer and accesses the data).

[benjaminwinger]

It appears that statically linking kuzu.lib to the extensions on windows makes the ABI somewhat unstable.