v1.2.0

fix: Fix invalid code generated for a plain array type (#18)

A property declared "type": "array" produced a class that does not parse.
Unlike string[] or FooTransfer[], a plain array carries no element type, and
three places assumed one was always present:

- macros.twig emitted both initialisers for a nullable array, giving
  `private ?array $body = [] = null;`
- class.twig appended an "add" method to every array property, so with no
  element type or singular it emitted `public function add( $): self`
- the @var, @return and @param docblocks rendered the element type
  unconditionally, giving `array<>` and `array|null<>`, and placed the
  generic after |null

DefinitionProvider now handles a plain array explicitly, documenting it as
array<mixed> and leaving the singular unset. The add method is emitted only
when a singular exists, and the initialiser is chosen rather than
concatenated: null when nullable, [] otherwise.

Only definitions that previously produced invalid PHP change. The existing
expected-output fixtures are untouched, which is what shows scalars, typed
arrays, transfer arrays and namespaced classes still generate byte for byte
as before.

A plain array may now be nullable. The typed-array restriction is unchanged,
since ArrayTypeNullableException still guards types ending in [].

Fixtures live in tests/Data/PlainArray so the shared Data set, and the tests
asserting against it, stay as they are.