Implement full fetch specification

[flyingsilverfin]

Usage and product changes

We refactor Fetch and Function behaviour, to allow any of the following Fetching patterns:

match
...
fetch {
    // fetch a matched attribute, value, or type. Represented as a attribute/value/type or null (if the variable is optional).
    "single variable": $a,   

    // attribute 'age' of $x. Must be `@card(0..1)` or `@card(1..1)`. Represented as an attribute or null.
    "single-card attributes": $x.age,

    // all attributes 'name' of $x. Can be any cardinality.
    "list higher-card attributes": [ $x.name ], 

    // inline-computed expression value. Represented as a value.
    "single value expression": $a + 1,  

    // an inline query with a 'return' block to select a *single* answer. Represented identically to a single variable or null.
    "single answer block": (  
        match
        $x has name $name;
        return first $name;
    ),

    // an inline query with a 'return' block to reduce to a *single* answer. Represented as a value or null
    "reduce answer block": ( 
        match
        $x has name $name;
        return count($name);
    ),

    // an inline query that returns a stream of lists/tuples. Represented as list of lists.
    "list positional return block": [  
        match
        $x has name $n,
            has age $a;
        return { $n, $a };
    ],

    // an inline query that returns stream of sub-documents. Represented as a list of objects.
    "list pipeline": [ 
        match
        $x has name $n,
            has age $a;
        fetch {
            "name": $n
        };
    ],

    // special syntax to fetch all attributes of a concept. Represented as an object, where keys are attribute type names and values are either lists (for >card(1)) or nullable values (for card(0..1) or card(1..1))
    "all attributes": { $x.* }
}

Implementation

[typedb-bot]

PR Review Checklist

Do not edit the content of this comment. The PR reviewer should simply update this comment by ticking each review item below, as they get completed.

---

Trivial Change

• [x] This change is trivial and does not require a code or architecture review.

Code

• [ ] Packages, classes, and methods have a single domain of responsibility.
• [ ] Packages, classes, and methods are grouped into cohesive and consistent domain model.
• [ ] The code is canonical and the minimum required to achieve the goal.
• [ ] Modules, libraries, and APIs are easy to use, robust (foolproof and not errorprone), and tested.
• [ ] Logic and naming has clear narrative that communicates the accurate intent and responsibility of each module (e.g. method, class, etc.).
• [ ] The code is algorithmically efficient and scalable for the whole application.

Architecture

• [ ] Any required refactoring is completed, and the architecture does not introduce technical debt incidentally.
• [ ] Any required build and release automations are updated and/or implemented.
• [ ] Any new components follows a consistent style with respect to the pre-existing codebase.
• [ ] The architecture intuitively reflects the application domain, and is easy to understand.
• [ ] The architecture has a well-defined hierarchy of encapsulated components.
• [ ] The architecture is extensible and scalable.