Handle table ID / rootpages properly for both checkpointed and non-checkpointed tables

Table ID is an opaque identifier that is only meaningful to the MV store.
Each checkpointed MVCC table corresponds to a single B-tree on the pager,
which naturally has a root page.

We cannot use root page as the MVCC table ID directly because:
- We assign table IDs during MVCC commit, but
- we commit pages to the pager only during checkpoint
which means the root page is not easily knowable ahead of time.

Hence, we:

- store the mapping between table id and btree rootpage
- sqlite_schema rows will have a negative rootpage column if the
  table has not been checkpointed yet.

tests/integration/query_processing/test_transactions.rs

@@ -571,7 +571,7 @@ fn test_mvcc_recovery_of_both_checkpointed_and_noncheckpointed_tables_works() {
         let value = i * 10;
         execute_and_log(
             &conn,
-            &format!("INSERT INTO test1 (id, value) VALUES ({}, {})", i, value),
+            &format!("INSERT INTO test1 (id, value) VALUES ({i}, {value})"),
         )
         .unwrap();
         expected_rows1.push((i, value));
@@ -592,7 +592,7 @@ fn test_mvcc_recovery_of_both_checkpointed_and_noncheckpointed_tables_works() {
         let value = i * 20;
         execute_and_log(
             &conn,
-            &format!("INSERT INTO test2 (id, value) VALUES ({}, {})", i, value),
+            &format!("INSERT INTO test2 (id, value) VALUES ({i}, {value})"),
         )
         .unwrap();
         expected_rows2.push((i, value));