Promote DateTime property type to NeoWiki core

[malberts]

Result of back-and-forth with @malberts.
Context: the NeoWiki codebase, the existing built-in property types
(Text/Url/Number/Select/Relation), and the in-tree RedHerb test extension
where DateTime previously lived.
_{Written by Claude Code, Opus 4.7 (1M context)}

Move the dateTime PropertyType backend from the RedHerb test extension into
NeoWiki core, alongside the other built-in types. The frontend already lived
in NeoWiki, so this completes the migration.

• DateTimeType and DateTimeProperty move to src/Domain/PropertyType/Types/
  and src/Domain/Schema/Property/.
• Registered via PropertyTypeRegistry::withCoreTypes() and
  Neo4jValueBuilderRegistry::withCoreBuilders(), using the shared $toScalars
  builder — matching what RedHerb did.
• RedHerb keeps Color as the canonical extension-point example.
• The two RedHerb-specific DateTime assertions in NeoWikiRegistrationHookTest
  are dropped; equivalent core coverage is added via the moved
  DateTimePropertyTest, a new DateTimeTypeTest, and an extra
  hasBuilder( 'dateTime' ) assertion in Neo4jValueBuilderRegistryTest.

No behaviour changes.

[alistair3149]

Result of code review with @alistair3149.
Context: the NeoWiki codebase, specifically the sibling property type registrations and test patterns under src/Domain/PropertyType/Types/ and tests/phpunit/Domain/....
_{Written by Claude Code, Opus 4.7 (1M context)}

Reviewed the diff against the surrounding code. No blockers — the move is mechanically correct, behaviour-preserving ($toScalars matches the prior fn ( $value ) => $value->toScalars()), namespaces line up with sibling types, the frontend typeName = 'dateTime' matches DateTimeType::NAME, and no DateTime references are left behind in tests/RedHerb/.

A couple of minor test-shape items worth tracking, both introduced by this PR:

1. Duplicate test — DateTimeTypeTest::testBuildPropertyDefinitionFromJsonReturnsDateTimeProperty is functionally identical to DateTimePropertyTest::testBuildPropertyDefinitionFromJsonViaType (same setup, same 'minimum' value, same assertions). Sibling *TypeTest classes (NumberTypeTest, UrlTypeTest, RelationTypeTest, TextTypeTest) are deliberately tiny and only cover getDisplayAttributeNames(). Suggest dropping the duplicate from DateTimeTypeTest to match.
2. testValueTypeIsString in DateTimeTypeTest is uneven with siblings — none of the other *TypeTests assert getValueType(). Either drop it for consistency, or extend the same assertion to siblings in a follow-up.

Optional follow-up (not specific to this PR): DateTimePropertyTest could adopt the assertSerializationDoesNotChange round-trip pattern used by NumberPropertyTest / TextPropertyTest via PropertyTestCase, to exercise the registry-driven PropertyDefinition::fromJson() path.