feat: `SnoopyView` to support option for passing schema

[PatrykWyzgowski]

Feature description

Add SnoopyView which is a type of View with loosend db-ally assumptions and runs user-defined method for accessing a schema.

Motivation

The db-ally usage allows for defining filters and aggregations but they bump into significant trade-off: genericness vs performance.
E.g. preferable (in terms of UX) implementation of an aggregation would be as follows:

@decorators.view_aggregation()
def count_by_column(self, filtered_query: sqlalchemy.Select, column_name: str) -> sqlalchemy.Select:
        select = sqlalchemy.select(getattr(filtered_query.c, column_name),
                                   sqlalchemy.func.count(filtered_query.c.name).label("count")) \
            .group_by(getattr(filtered_query.c, column_name))
        return select

Please not that such implementation delegates the column name resolution to LLM which can impact the performance (LLM can poorly guess the column name).

To address the performance issue one can implement a method with the name of the column to be used directly:

@decorators.view_aggregation()
def count_by_university(self, filtered_query: sqlalchemy.Select) -> sqlalchemy.Select:
        select = sqlalchemy.select(filtered_query.c.university),
                                   sqlalchemy.func.count(filtered_query.c.name).label("count")) \
            .group_by(filtered_query.c.university)
        return select

This creates a risk of creating vast amount of boilerplate assuming general-purpose View.
Some db-ally (or Text2SQL) user might prefer generic filters/aggregations usage and boost performance in favor of decoupling the database structure from the prompt. Such nosy SnoopyView might ask implicitly for the structure to use it in a prompt or inject additional few-shot examples.

Additional context

NosyView was initially considered but SnoopyView synonym additionally refers to a dog used together with the library name 🦮.