Release Release v2.3.0 · Cratis/Screenplay

Added

form <Name> for <Command> - a named, module-level input surface bound to a command. Declared alongside layout inside a module, and discovered by its for binding wherever that command is invoked, rather than referenced from a screen's directive tree.
populate via query <Query> [by <param>] and populate from item - seed a form's initial values from a query result or an already-bound item in scope.
field <property> [from <source>|compose using <Callback>] [label "<text>"] - bind a form field to a command property, with an explicit rename, a compositional callback, or a display label.
on submit navigate to <Screen> [by <param>] - navigate after a successful submit, reusing the same navigation shape screens already use.
The command a form binds to, the query it populates from, and the screen it navigates to on submit resolve the same inside-out way every other bare name in the document does, warning when nothing in scope declares them.
Every field a form declares now must bind to a property its command actually has - the same rename-breaks-the-build guarantee AutoMap already gives a projection.
New Forms documentation page, and a correction to the Screens page, which named forms as a screen widget even though no such widget exists.

ModuleSyntax.Forms was added as a trailing optional parameter (not inserted between Layouts/Features) to keep the change source- and binary-compatible with existing callers, matching the convention ApplicationSyntax.UiProfiles already established.
The issue's open questions (compose-using callback scope, reusing one form shape across multiple commands) are left for a follow-up - this PR implements the syntax, printing, and the validations the issue calls out explicitly as required, without pre-deciding those two open design questions.
CI's publish-dotnet-packages job is expected to fail on this PR - it's a pre-existing, repo-wide CS9057 analyzer/compiler version mismatch (Microsoft.Net.Compilers.Toolset pinned to 5.6.0 vs. the runner SDK's 5.9.0+ codestyle analyzers), unrelated to this change and already occurring on main. See PR #97 for the same failure and its investigation.