Release v4.72.0

A rendered Cratis application can now render a ui profile that names a custom runtime package: the application approves the package with Scene's approved package set, and the generated frontend installs, loads and renders it.

Added

• CratisRendering.CreateProfile(..., approvedPackages) carries an approved package set in the render profile as approved-packages.json and generates the frontend that installs and loads it: one extra package.json dependency per package, .frontend/approvedPackages.ts (literal imports, package style sheets, loadApprovedComponents() over Scene's loadApprovedPackages) and a main.tsx that awaits it before the first render. An application with no approved packages plans byte-for-byte what it planned before. Admission regenerates the whole frontend from the document and refuses a profile that differs (STAGE-CRATIS-001). See Custom runtime packages. (part of #236)
• CratisRendering.ShippedPackages, ShippedPackageNames and CatalogWith(set): the catalog a ui profile resolves against is the packages the target ships plus the approved ones, so an approved package's layouts, themes, dependencies and version ranges are checked by the same planner. (part of #236)
• CratisBackendApplicationScaffoldRequest.WithApprovedPackages refuses a package that reuses a shipped package name or an npm package the scaffold already installs. (part of #236)
• The Stage App takes a packageCatalog, so an authored component Acme.Charts.chart (or a bare name only an approved package declares) resolves to the key the package registers its component under instead of rendering "Unresolved component". (part of #237)

Changed

• Rendered applications and the live Stage use Scene 4.20.0 (@cratis/scene.* and Cratis.Scene.*), which publishes the approved package set loader. (part of #236)
• Verification/generated-react-browser/run.sh runs another scenario script when STAGE_GENERATED_REACT_SCENARIO names one, so a rendered application with a custom package can be held to its own assertions. (part of #236)