fix(catalog): consistent ordering of catalog operations

[jacksonrnewhouse]

Closes #25667

In looking at addressing #25667 I found a class of race conditions related to inconsistencies between the ordering of catalog operations against the in-memory Catalog versus how they were written to the WAL. For example, if write calls A and B are both writing to table foo, one might create the table while the other adds some field. If the order of the WAL calls is different than the order of the original invocations the system will fail on restoration, as it'll receive a field addition for a table it hasn't yet created.

The new approach is for the WalOps to be take an OrderedCatalogBatch, which will have been produced by calling apply_catalog_batch. We then sort the WalOps by a newly defined order, putting the catalog ops first, sorted by catalog_sequence_number.

Following on the work in #25642, I've removed the dedicated methods add_meta_cache(), remove_meta_cache(), add_last_cache(), delete_last_cache(), instead relying on the apply_catalog_batch() method. @hiltontj, can you take a look to make sure this was done safely?

[pauldix]

PR and commit subject should be fix: consistent ordering of catalog operations with the space after the :

[pauldix]

I think this looks good, but I'd like @hiltontj to have a look too.

[hiltontj]

This looks good to me @jacksonrnewhouse - removing the create/delete methods on the catalog for the last/meta caches looks a lot cleaner and also looks sound to me.

👍 on having all changes go through a single point (apply_catalog_batches).

I left a couple comments on things I noticed but they are not blockers for this PR.