added `Select` to define transitions

[zilto]

Following #359, this PR introduces Select as an alternative to Condition when defining "one to many" transitions.

Not only can this be more ergonomic for developers, it allows to resolve multiple conditions at once. This was impossible before and conditions were only binary checks evaluated sequentially.

For example, this is now a valid Graph definition

import random
from burr.core import action, ApplicationBuilder, State, Select, Action

def random_decider(state: State, actions: list[Action]) -> str:
    action_idx = random.randint(0, len(actions)-1)
    return actions[action_idx].name

app = (
    ApplicationBuilder()
    .with_actions(
        process_user_input, generate_text, generate_image,
        ask_user_for_details, send_response
    )
    .with_transitions(
        (
            "process_user_input",
            ("generate_text", "generate_image", "ask_user_for_details"),
            Select(["user_query"], resolver=random_decider),
        ),
        (
            ("generate_text", "generate_image", "ask_user_for_details"),
            "send_response"
        ),
        ("send_response", "process_user_input"),
    )
    .with_entrypoint("process_user_input")
    .build()
)

Changes

• Added the Select construct
• Updated the .get_next_node() and .with_transitions() of Graph and GraphBuilder to support Select
• Updated the GraphBuilder() and ApplicationBuilder() type annotations to receive Select
• Updated the GraphBuilder() and ApplicationBuilder() type annotations to use Sequence instead of List

How I tested this

• Added two tests to create Select objects and call the .run() method
• all previous tests are still passing

Potential TODOs

• add a default kwarg to Select. This could be the default Action to use if the resolver returns None for instance
• Allow the resolver to directly return an Action or an integer index of the action instead of action_name: str
• Properly type the Select.resolver because it currently dislikes user-provided functions annotated with list instead of Sequence

TODOs

• Add Select to the main docs
• Add docstring documentation with examples (where exactly? directly on Select? Should I update .with_transitions() of other objects?)
• Create an examples/ that uses an LLM to decide the next action (see #359)

Checklist

• [x] PR has an informative and human-readable title (this will be pulled into the release notes)
• [ ] Changes are limited to a single goal (no scope creep)
• [x] Code passed the pre-commit check & code is left cleaner/nicer than when first encountered.
• [x] Any change in functionality is tested
• [ ] New functions are documented (with a description, list of inputs, and expected output)
• [x] Placeholder code is flagged / future TODOs are captured in comments
• [ ] Project documentation has been updated if adding/changing functionality.