Per Dart 3.10 dot-shorthand and the patterns specification, a
dot-shorthand expression may appear as a constant pattern, e.g.

    switch (c) {
      case .red:        // static member dot-shorthand
      case .new():      // default constructor dot-shorthand
      case .fromRGB(1): // named constructor dot-shorthand with args
    }

and `const` may prefix a dot-shorthand constructor invocation, with the
receiver type inferred from context:

    const Color c = const .new();
    const Color d = const .fromRGB(1, 2, 3);

Adds:
  - `$.dot_shorthand` (optionally followed by type arguments and an
    arguments list) as a `constant_pattern` choice.
  - `seq($.const_builtin, $.dot_shorthand, $.arguments)` as a second
    alternative in `const_object_expression`.

Reference: Dart Language Specification — Dot Shorthands and Patterns.

Per the Dart specification, `get` and `set` are built-in identifiers
(not reserved words) and may be used as ordinary identifiers — for
example as the name of a local variable or a class field with an
explicit type. The `_declared_identifier` rule already aliases
`_get`/`_set` to `identifier`; mirror that on `initialized_identifier`
so declarations like

    class C {
      int set = 0;
      String get = 'foo';
    }

parse correctly. Without this change, the grammar fell back to the
getter/setter declaration rules (which require an initializer-less
signature) and failed in real-world packages such as `sqlparser` and
`s_packages` that use `set`/`get` as field names.

Adds GLR conflicts so the parser keeps the variable-declaration and
getter/setter signature paths open while reading `Type get` /
`Type set`.

Reference: Dart Language Specification — Built-in Identifiers
(`get`, `set`) and Variable Declaration / initializedIdentifier.

Per the Dart specification, `get`, `set`, and `Function` are built-in
identifiers and may appear as ordinary identifiers — including on the
left-hand side of an assignment, or as the receiver of a method call.

Real-world packages such as `sqlparser` (`set = ...`) and
`auro_stream_live` (`Function.apply(...)`) failed to parse because:

- `assignable_expression` only accepted `$.identifier` for the
  bare-identifier case, so `set = expr` and `get = expr` parsed as
  the start of a setter/getter signature instead of an assignment.
- `_primary` did not include `Function` as an identifier, so
  `Function.apply(args)` could not be parsed as a method call (the
  `Function` class is referenced by name).

Adds aliased `_get`, `_set`, and `_function_builtin_identifier`
choices to both `_primary` and `assignable_expression`, plus the
required GLR conflicts (`_primary` vs. `_type_not_void_not_function`
/ `_function_type_tail`) so the parser can still recognize `Function`
as part of a function type (`Function(int)`, `Function?`).

Reference: Dart Language Specification — Built-in Identifiers
(`get`, `set`, `Function`).

Two related Dart 3 declaration forms were missing:

1. Abstract instance fields. Per the Dart spec, an instance field
   inside an abstract class may be declared without an initializer
   using the `abstract` modifier; the field has no implementation and
   subclasses must provide a concrete getter/setter. Forms supported:
       abstract <type>? <ids>;
       abstract final <type>? <ids>;
       abstract covariant <type>? <ids>;
   Affects packages such as `embrace`, `crypto_wallet_util`, and
   `catalyst_builder`.

2. Top-level external variable declarations. Used by `dart:js_interop`
   patterns such as `@JS() external _DdLogs? DD_LOGS;`. The existing
   `_top_level_definition` choice supported `external function/getter/
   setter` signatures but not external variables. Forms supported:
       external <type>? <ids>;
       external final <type>? <ids>;
       external late <type>? <ids>;
   Affects packages such as `datadog_flutter_plugin`, `dwds`, and
   `ditto_live`.

Reference: Dart Language Specification — Abstract Instance Variables
and (Static) External Variables.

Two more built-in identifier sites the grammar did not yet treat as
ordinary identifiers:

- `label` only accepted `\$.identifier`, so named arguments like
  `f(get: x, set: y)` failed to parse. Real-world example:
  `datahub_aperture` constructs `ResourceEndpoint(get: ..., post: ...)`.
- `initialized_identifier` and `_declared_identifier` did not accept
  `operator` as an identifier, so `String operator;` did not parse.
  Real-world example: `ffastdb` declares a `String operator;` field.

Adds aliased `_get`, `_set`, `_function_builtin_identifier` choices
to `label`, and aliased `_operator` to both `initialized_identifier`
and `_declared_identifier`. Also adds a GLR conflict between
`operator_signature` and `_var_or_type` so the parser keeps both
the operator-method-signature path (`Type operator +(...)`) and the
variable-declaration path (`Type operator;`) open.

Reference: Dart Language Specification — Built-in Identifiers
(`get`, `set`, `operator`, `Function`).

Per the Dart specification, a single `;` is the empty (null) statement.
It can appear anywhere a statement is expected, e.g. as the body of an
`if (cond) ;` form, after a `return;` continuation, or as a stray `;`
in a function body. The grammar previously had no rule for this, so
real-world code using it failed to parse.

Adds an `empty_statement` rule and includes it in `_statement`. Affects
packages such as `crypto_wallet_util` (`if (!isUint(n, 53)) ;`) and
`littlefish_feature_user_pins` (`return; ;`).

Reference: Dart Language Specification — Statements (emptyStatement).

Per the Dart specification (Static Interop / External Members), a
class instance field may be declared with the `external` modifier in
combination with `final` or `covariant`. The grammar previously
covered only the bare `external <type> <id>` form (via the
`_external_and_static + _type + identifier` rule), so

    extension type _Foo._(JSObject _) implements JSObject {
      external final JSString field;
    }

failed to parse. Affects `dart:js_interop` extension types in
packages such as `ditto_live`.

Adds two new declaration alternatives:
  external final <type>? <id-list>
  external covariant <var-or-type> <id-list>

Per the Dart spec, expression lists generally allow trailing commas.
The C-style for-loop's update list (`for (init; cond; u1, u2,)`) was
parsed with `commaSep` (no trailing comma); switch to
`commaSepTrailingComma` so code such as

    for (var i = 0; i < n; i += 15,) { ... }

parses. Affects packages such as `pdf_plus`.

Per Dart spec the right-hand side of a constructor field initializer
is a full `expression`, including compound assignments such as `??=`.
The grammar restricted it to `_real_expression`, which excluded
assignment expressions, so code such as

    A(int? x) : x = x ??= 5;

failed to parse. Real-world examples in `matrix` (constructor body
chained `??=` assignments) and `syncfusion_flutter_gauges`.

Reference: Dart Language Specification — Constructor field
initializers (`fieldInitializer`).

Per Dart 3 (null-aware elements), a map entry may use `?` before the
key as well as before the value to mark the corresponding sub-
expression as null-aware:

    {
      ?maybeKey: 1,         // omit entry if maybeKey is null
      key: ?maybeValue,     // omit entry if maybeValue is null
      ?maybeKey: ?maybeValue,
    }

The grammar previously allowed `?` only before the value. Adds
`optional('?')` before the key in the `pair` rule. Affects packages
such as `analyzer` and `drift_dev`.

Reference: Dart Language Specification — Null-aware elements.

Cascades like `obj.._parent!.onChildrenChanged(this)` fail to parse
because the cascade subsection rule only allowed an assignable selector
followed by argument parts, with no way to apply the postfix `!` null
assertion between selectors. The non-cascade `selector` rule already
handles this via the general selector form.

Mirror that here: after the leading cascade selector and after each
subsection's assignable selector, accept argument parts and `!`
interleaved. This matches the shape Dart programs actually use when
chaining null-asserted member access in cascades (common in flame,
flutter widget code, etc.).

`dart:ffi` Struct definitions sometimes declare external fields whose
name is a built-in identifier (`get`, `set`, `operator`). For example
in the `colibri_stateless` package:

    @ffi.Packed(1)
    final class colibri_StatusCondition extends ffi.Struct {
        external colibri_StatusCondition_DataType get;
    }

These names are reserved keywords only in restricted contexts; in field
declarations they are valid identifiers. Accept them as aliases of
`identifier` in the static external field arm so packages using ffi
struct conventions parse cleanly.

Dart 2.19+ allows the library directive to be written without a name
(`library;`) so the file can carry a doc comment or annotation that
documents the library as a whole, without forcing the author to invent
a globally-unique library identifier. The reference is the language
versioning in the Dart language spec section 'Libraries' (the library
declaration's name part is optional since the library declaration
syntax was clarified for the unnamed-library form).

Without this, the parser inserts a synthetic MISSING identifier and
emits a partial parse for any file that uses the form, e.g.
`just_storage`'s `example/di_setup_example.dart` and many other
documentation-only library files.

Per the Dart language spec section 'Symbols', a symbol literal accepts:
- a single identifier or dotted identifier list (e.g. `#a.b.c`)
- a single operator token (e.g. `#+`, `#==`, `#[]`, `#[]=`, `#~`)

The previous grammar only accepted `#identifier`, so common forms used
in serialization/codegen libraries (e.g. `firebase_dart`'s
`#UploadTask.pause` and `build_runner` symbol-as-key patterns) failed
to parse.

A record literal with exactly one named field requires a trailing
comma (`(name: value,)`) to be unambiguously a record rather than a
labeled parenthesized expression. The grammar previously accepted
`(label: expr)` (no comma) and `(label: expr, more,)` (2+ fields)
but rejected the unambiguous single-named-field form.

This pattern shows up in real code returning records with one named
component, e.g. `return (prefix: syntheticImport.prefix,);`. See
Dart 3 record literal grammar in the language spec.

When this branch added `alias($._operator, $.identifier)` to
`initialized_identifier` and `_declared_identifier` (so that
`String operator;` parses), the parser started accepting the
`'operator'` keyword token in identifier position. Tree-sitter still
emits the underlying anonymous keyword node, so the global
`"operator" @keyword` query in highlights.scm fired in places where
`operator` is being used as a variable name (e.g. `var operator = 1;`),
breaking the `keywords.dart` highlight test.

Fix: drop `"operator"` from the global keyword list and add a scoped
query that highlights it as a keyword only inside `operator_signature`.
Mirrors the existing pattern used for `get`/`set` (which already work
this way and pass the same test).