[Feature Request]: Add Columns Retrievers in NLSQLRetriever

### Feature Description

In addition to the `rows_retrievers`, the `NLSQLRetriever` class should support an optional `cols_retrievers` or `values_retrievers` parameter (the most relevant name for this parameter can be discussed). This allows retrieving relevant values for individual columns instead of entire rows, providing more efficient contexts for text-to-SQL.

Example:

```python
# Create database, column retrievers, and LLM...
...

# Define column-specific retrievers for each table
cols_retrievers = {
    "city": {
        "name": city_name_retriever,
        "country": city_country_retriever,
    }
}

# Initialize the text-to-SQL retriever
text_to_sql_retriever = NLSQLRetriever(
    sql_database=database,
    tables=["city"],
    llm=_llm,
    cols_retrievers=cols_retrievers,
)
```

This would result in the following context being generated:

> Table 'city' has columns: name (VARCHAR(64)), country (VARCHAR(64)), .
> Here are some relevant values of text columns:
> name: Paris, New-York, London
> country: Germany, Spain, China

One important consideration when implementing this feature is the potential increase in token usage and latency at query time. A naive implementation might pass the query to all column retrievers, each independently embedding it for retrieval, resulting in redundant computation and unnecessary overhead. To mitigate this, the feature should optimize query routing—for example, by introducing an optional embedding parameter in the NLSQLRetriever class. If provided, the query embedding could be computed once and reused across all column retrievers, reducing both token usage and latency.

### Reason

Currently, the `NLSQLRetriever` does not support fine-grained retrieval at the column level for SQL tables. It primarily operates at the row level via rows_retrievers. 
This means the context passed to the language model often includes entire rows, even when only a few columns are semantically relevant to the user query. This can dilute the relevance of the context and introduce unnecessary noise, especially for wide tables.

In addition, some columns contain categorical values (e.g., country, status, department) that are either highly repetitive across rows or rarely retrieved when using row-level embeddings.
 As a result, relevant column values can be entirely missed, especially when they don't co-occur with other highly ranked row features. 
Indexing columns individually would reduce token overhead during ingestion, eliminate redundancy, and improve the retrieval of relevant values independently of other columns' content.


### Value of Feature

Column-level retrieval should enable more focused and efficient context generation by retrieving only the most relevant values for specific columns instead of entire rows. 
It should reduce token usage during data ingestion, improve precision, and ensure better coverage of categorical values that are often repetitive or missed in row-level retrieval. 
It should also enhance accuracy in wide or complex schemas and support modular, column-specific retrieval strategies, leading to more reliable text-to-SQL generation.

Labels: enhancement, triage
State: closed