Additional unsafe deserializers

[chanel-y]

Adding the unsafe deserializers available in csharp but now in powershell!

Weird thing about this PR is how it splits up the different kinds of .NET APIs are invoked in powershell:

InstanceDeserializerSink — Creates an object, then calls a method on it:

$fmt = New-Object System.Runtime.Serialization.Formatters.Soap.SoapFormatter
$fmt.Deserialize($stream) # ← sink is $stream

Requires tracking that $fmt was created as an unsafe type, then matching the method call on it.

StaticDeserializerSink — Call a static method directly on the type (no object creation):

[System.Windows.Markup.XamlReader]::Parse($xaml) # ← sink is $xaml

No New-Object involved — just [Type]::Method(). Needs different matching logic (check isStatic() + the type qualifier).

UnsafeConstructorSink — The constructor itself is the dangerous operation (not a follow-up method):

$r = New-Object System.Resources.ResourceReader -ArgumentList $pat

ResourceReader deserializes the resource file at construction time, so the constructor argument is the sink

Each of the deserializers is classified into of the above, except BinaryFormatter which is separate since it's still used by the BinaryFormatter query

[MathiasVP]

Slightly less API-graphy than I was hoping for, but it does the job so I don't see a reason not to get this merged. Great job, Chanel and Copilot!

We should investigate at some point whether API graphs can make these very syntax-driven predicates more general, but that does not need to be now.