[Feature]: Project-mode support for `winapp package`

[nmetulev]

Is your feature request related to a problem? Please describe.

winapp package currently requires users and agents to build the app first and locate the correct package-layout folder. For .NET projects, this adds avoidable output-path discovery and makes winapp package inconsistent with winapp run, which now accepts a .csproj, builds it, and resolves its output.

Describe the solution you'd like

Support an explicit .csproj as a single input, for example:

winapp package .\MyApp.csproj

In project mode, the command should:

• Build and evaluate the project using the same project-resolution infrastructure as winapp run rather than duplicating MSBuild/output-path logic.
• Resolve the built package layout and manifest, then pass them to the existing MSIX packaging pipeline.
• Support the relevant project build options from winapp run (configuration, architecture, framework, --no-build, --no-restore, and repeatable MSBuild properties).
• Produce an actionable error when the project cannot produce a packageable layout.
• Preserve existing behavior for package-layout folder inputs, multi-folder bundle inputs, and sparse-manifest inputs.

Initial scope should treat only an explicit .csproj as project mode so existing directory inputs remain unambiguous.

Additional context

This is the packaging counterpart to #633, which added project-mode support to winapp run. The implementation should reuse or extract its build/evaluation and TargetDir resolution where practical.

Success criteria:

• winapp package MyApp.csproj builds the project and creates an MSIX.
• --no-build packages a compatible existing build output.
• Project build overrides are consistently honored during both build and output evaluation.
• Existing folder, bundle, and sparse-manifest workflows remain unchanged.