docs: use literalinclude instead of code-block on quickstart

[euri10]

Description

• put the code-block in their own quickstart_# files and use literalinclude in the quickstart.rst
• add /docs/examples/quickstart to pytest discover path
• add a test on each block, test that wont be shown in docs thanks to lines and dedent directives

Closes

fixes #167

[euri10]

@cofin I just moved things around, are examples folder in the docs tested somehow, I didnt take the time to investigate but I'm sure you'll know :)

[euri10]

re-reading this after i'm on other pages I realize that for instance we could do differently:

current option1:

from sqlspec import SQLSpec
from sqlspec.adapters.sqlite import SqliteConfig

# Create SQLSpec instance and configure database
db_manager = SQLSpec()
db = db_manager.add_config(SqliteConfig(pool_config={"database": ":memory:"}))

# Execute a query
with db_manager.provide_session(db) as session:
    result = session.execute("SELECT 'Hello, SQLSpec!' as message")
    print(result.get_first())  # {'message': 'Hello, SQLSpec!'}


def test_quickstart_1() -> None:
    assert result.get_first() == {"message": "Hello, SQLSpec!"}

could be option2:

def test_quickstart_1() -> None:
    from sqlspec import SQLSpec
    from sqlspec.adapters.sqlite import SqliteConfig

    # Create SQLSpec instance and configure database 
    db_manager = SQLSpec()
    db = db_manager.add_config(SqliteConfig(pool_config={"database": ":memory:"}))

    # Execute a query
    with db_manager.provide_session(db) as session:
        result = session.execute("SELECT 'Hello, SQLSpec!' as message")
    print(result.get_first())  # {'message': 'Hello, SQLSpec!'}
    assert result.get_first() == {"message": "Hello, SQLSpec!"}

and we use dedent like in the async test on this pr, idk which one is better:

• for the end user he'll see the same output in docs
• for maintenance it means just write a test for an example, I think I prefer option 2, wdyt @cofin ?

[cofin]

• for the end user he'll see the same output in docs
• for maintenance it means just write a test for an example, I think I prefer option 2, wdyt @cofin ?

If there's no change in the user output, I definitely think that a single function is much easier to maintain here. I'd go with option 2 as well.