Hint that a piped collection is unwrapped in single-value assertions

[nohwnd]

Piping a collection into an assertion that inspects a single value unwraps the collection first — a one-item collection becomes its single element, several items become [Object[]] — so the assertion never sees the collection you piped and fails with a confusing message. This started as a Should-HaveType fix (#2801), but the same surprise applies to every single-value and type assertion, so this PR generalises the hint.

On the failure path only, the assertion recovers the original piped value (via the PipelineSource trick) and appends a hint that explains exactly what the pipeline did.

A type assertion (Should-HaveType, Should-NotHaveType):

Expected value to have type [string[]], but got [Object[]] @('a', 'b').

Hint: You piped a [string[]] into a type assertion, but the pipeline streams a
multi-item collection and re-collects it as [Object[]], so the assertion saw
[Object[]], not the [string[]] you piped. To assert the type of a collection,
pass it as the -Actual argument instead of piping it, e.g. -Actual $value.

A single-value assertion (Should-Be, booleans, strings, comparisons, …), here a one-item collection (@(1) | Should-Be 2):

Expected [int] 2, but got [int] 1.

Hint: You piped a [Object[]] into a single-value assertion, but the pipeline
unwraps a single-item collection to its one element, so the assertion inspected
that single [int] instead of the collection. To assert on a collection use
Should-BeCollection or Should-BeEquivalent; to assert on a single value pass it
as the -Actual argument instead of piping it, e.g. -Actual $value.

What's covered

• Type: Should-HaveType, Should-NotHaveType.
• Value: Should-Be, Should-NotBe, Should-BeNull, Should-NotBeNull, Should-BeSame, Should-NotBeSame, Should-BeHashtable, the boolean assertions (Should-BeTrue, Should-BeFalse, Should-BeTruthy, Should-BeFalsy), and the string equality/emptiness assertions (Should-BeString, Should-BeEmptyString, Should-NotBeEmptyString, Should-NotBeWhiteSpaceString).
• Comparison & time: Should-BeGreaterThan / …OrEqual, Should-BeLessThan / …OrEqual, Should-BeAfter, Should-BeBefore. These threw a native conversion error when a piped multi-item collection was unwrapped to [Object[]]; the comparison is now wrapped so they fail cleanly with the hint, while a genuine non-pipeline error is still rethrown unchanged.

Notes

• The hint is computed only when an assertion is already failing, so the passing path is untouched.
• A genuinely piped scalar, an empty collection, or a value passed with -Actual does not trigger it. For type assertions a piped [Object[]] that stays [Object[]] is not flagged — nothing was lost.
• Deliberately left as-is: the wildcard/regex/-ne string assertions (Should-NotBeString, Should-BeLikeString, Should-NotBeLikeString, Should-MatchString, Should-NotMatchString) already reject a piped collection with their own collection-specific guidance, so they don't get this hint.
• All wording lives in one place (Get-AssertionGotcha) and is covered shape-by-shape in a new Get-AssertionGotcha.Tests.ps1, which drives the gotcha through a fake unrolling assertion and a fake non-unrolling one, plus an integration check that the real assertions wire the hint up.

Fix #2801