Enhancements for unique indexes on `BLOB`/`TEXT` columns with no prefix length

PR #7104 added support for creating unique secondary indexes on BLOB/TEXT columns without needing to specify a prefix length. There are a few follow-ups to that feature to make it more robust:
- **Better error message for unique constraint violation** – When a unique constraint violation error is returned for a content-hashed unique index, it currently returns the hashed value. This is not a very useful error message; the original value should be used instead.
- **Validating unique constraint violations against real value** – If a content hash matches, then there is a very high probability of a unique constraint validation, but to be 100% sure, we should check the non-hashed values and make sure we didn't hit a very rare false positive with a hash collision for two different values.
- **Support case-insensitive collations** – The current code only supports case-sensitive/accent-sensitive collations. If a case-insensitive collation is used on a TEXT column, and that column is used without a prefix length in a unique index, that will generate an error. This is to prevent the case where two values that should be considered identical in a case-insensitive context (e.g. "YES" and "yes") will not correctly trigger a unique constraint violation.

Start by reading PR #7104 and the implementation it introduced for unique secondary indexes on BLOB/TEXT columns without prefix lengths. Reproduce the three reported cases: error messages should show original values, hash matches should be checked against real values, and case-insensitive collations should work without allowing distinct values to bypass uniqueness.

Written by the indexing model from the issue text.