opt: index recommendations should be aware of hash sharding

[rytaft]

Is your feature request related to a problem? Please describe.
Today we give sub-optimal index recommendations for tables that contain hash-sharded indexes. For example:

CREATE DATABASE IF NOT EXISTS employees;
USE employees;
IMPORT PGDUMP 'https://s3-us-west-1.amazonaws.com/cockroachdb-movr/datasets/employees-db/pg_dump/employees-full.sql.gz' WITH ignore_unsupported_statements;
ALTER TABLE employees ALTER PRIMARY KEY USING COLUMNS (emp_no) USING HASH WITH BUCKET_COUNT = 8;
EXPLAIN SELECT * FROM employees AS OF SYSTEM TIME '-1s' WHERE emp_no > 10000 ORDER BY emp_no LIMIT 25;

The recommendation in this case is to recreate the non-hash-sharded pk as an index:

  index recommendations: 1
  1. type: index creation
     SQL command: CREATE INDEX ON employees (emp_no) STORING (birth_date, first_name, last_name, gender, hire_date);

Describe the solution you'd like
We should not recommend creating an index on a column if an equivalent hash-sharded index already exists. If a hash-sharded index already exists but does not store all of the needed columns, we could suggest dropping it and re-creating the hash-sharded index with additional STORING columns.

Epic: CRDB-14532
Jira issue: CRDB-17795

[michae2]

See also #41058 (comment) about providing a recommendation to hash-shard an index.