Summary:
I found that for pg_range, even if we add it to the list via
--ysql_catalog_preload_additional_table_list, only the base table is loaded (RANGETYPE with cache id
53), the index is not loaded (RANGEMULTIRANGE with cache id 52). From a customer case debugging,
both caches are needed at about the same rate (50 vs 50). We should also preload RANGEMULTIRANGE
when pg_range is preloaded. Otherwise we can see more cache misses from RANGEMULTIRANGE than
RANGETYPE.

I made a code change by preloading RANGEMULTIRANGE in addition to RANGETYPE itself.

Added a new unit test, of which PgRangeTest.PgRangeCatalogCacheTest/1 would fail before the fix.
Jira: DB-18737

Test Plan: ./yb_build.sh release --cxx-test pg_libpq-test --gtest_filter PgRangeTest.PgRangeCatalogCacheTest/*

Reviewers: kfranz, sanketh

Reviewed By: sanketh

Subscribers: yql, sanketh

Differential Revision: https://phorge.dev.yugabyte.com/D47561