Add hint and one-click copy for the three independent CLI-argument fields

[Scott (7ranceaddic7)]

• I have read the contributing guidelines, and I agree with the Code of Conduct.
• Have you checked that there aren't other open pull requests for the same changes?
• Have you tested that the committed code can be executed without errors?
• Have you confirmed that this issue is caused by UniGetUI itself, and not by the package manager or the package involved?

---

Follow-up to #5037. That PR fixed a misleading log label; this one addresses the underlying UX gap that caused the confusion in the first place.

CustomParameters_Install, CustomParameters_Update, and CustomParameters_Uninstall are three independent fields, shown as three separate rows on both the per-manager default-options settings panel (InstallOptionsPanel) and the per-package install-options dialog (InstallOptionsControl). Nothing on either screen indicates that these fields are independent -- a user reaching for "Custom install arguments" (the first row, and the one most naturally filled in first) has no signal that the same argument won't be applied on update or uninstall, and finds out only when an update fails for a reason that looks unrelated.

Change, on both screens:

• A short hint text above/near the three fields: "These fields are independent: an argument set for Install won't apply to Update or Uninstall, and vice versa."
• A "Copy install arguments to update and uninstall" link, for users who do want the same argument applied everywhere, so they don't have to retype it three times (and so the omission becomes a visible, deliberate non-action rather than an invisible default).

No behavior change to the underlying InstallOptions engine -- this only affects the two settings screens. New strings added to src/Languages/lang_en.json following the existing convention (see e.g. #4902).

Verified with dotnet build on UniGetUI.Avalonia.csproj (0 errors) against SDK 10.0.301 -- Avalonia's compiled x:DataType bindings fail the build on any binding-name typo, so a clean build confirms the new bindings (CliArgsHintLabel, CopyInstallArgsLabel, CopyInstallArgsToOthersCommand) resolve correctly on both views.

N/A. No existing issue tracks this; not creating one per the PR template guidance.

[Scott (7ranceaddic7)]

Real-world verification of the scenario this PR is meant to prevent:

The whole point of the hint + "Copy install arguments to update and uninstall" link is: once a user correctly populates CustomParameters_Update (instead of only CustomParameters_Install, which was the original mistake this surfaced from), the update should actually succeed. Confirmed that end to end on a real machine, not just in the abstract:

1. Called the real manager.OperationHelper.GetParameters(package, options, OperationType.Update) (the same code path this dialog's live command preview uses) with CustomParameters_Update = ["--legacy-peer-deps"] populated (i.e. the state a user reaches after using the new copy link, or after correctly filling in the Update field on their own). It produced:

   npm install 'markdownlint-cli2@0.23.0' --legacy-peer-deps
   

2. Ran that exact command against a real project with the ESLint-9/10 peer conflict this flag exists to work around. Result: exit code 0, "up to date, audited 357 packages," 0 vulnerabilities, no ERESOLVE.

Done via a temporary local test calling GetParameters directly (not committed), then executing the returned command for real. No changes to this PR's diff. This just substantiates that the UX change points users toward a state that actually works.