cli: support \l+ for table and database size

[dbist]

Is your feature request related to a problem? Please describe. Today it is difficult to tell what a table or database size is w/out looking at the DB Console. It requires running a query similar to

WITH range_stats AS (
SELECT table_name, index_name, range_id, crdb_internal.range_stats(start_key) AS stats
FROM crdb_internal.ranges_no_leases
WHERE database_name = 'movr'
)
SELECT table_name, index_name, round(sum((stats->>'key_bytes')::INT + (stats->>'val_bytes')::INT)/1024/1024) AS MiB, count(*)
FROM range_stats
GROUP BY table_name, index_name
ORDER BY MiB desc;

to provide logical table size before replication. In Postgres, you can easily get database size with a command \l+. Given our promise to be PG-compatible, we should support the same UX.

Describe the solution you'd like

I would like to see output similar to

List of databases
   Name    | Owner | Encoding | Collate | Ctype | Access privileges |  Size   | Tablespace |                Description                 
-----------+-------+----------+---------+-------+-------------------+---------+------------+--------------------------------------------
 postgres  | artem | UTF8     | C       | C     |                   | 8665 kB | pg_default | default administrative connection database
 template0 | artem | UTF8     | C       | C     | =c/artem         +| 8545 kB | pg_default | unmodifiable empty database
           |       |          |         |       | artem=CTc/artem   |         |            | 
 template1 | artem | UTF8     | C       | C     | artem=CTc/artem  +| 8665 kB | pg_default | default template for new databases
           |       |          |         |       | =c/artem          |         |            | 
(3 rows)

Or perhaps adding a column to the output of show ranges from table command.

Jira issue: CRDB-18461

[rafiss]

could end up relating to https://github.com/cockroachdb/cockroach/issues/86017

[knz]

NB: the idea to use range stats is not good as explained in epic CRDB-22711.

[knz]

With the new implementation, we will indeed be able to benefit from the solution to #86017 directly.