Add structured Publicize item metadata

[krafs]

Adds a structured item form where Namespace and Type are their own metadata instead of being packed into the Include string. Additive — the colon-string form is unchanged.

<Publicize Include="MyAssembly" Namespace="MyNamespace" />
<Publicize Include="MyAssembly" Namespace="MyNamespace" Type="MyType.MyNestedType" />
<Publicize Include="MyAssembly" Namespace="MyNamespace" Type="MyType{TKey,TValue}" />

Splitting Namespace out is what removes the namespace-vs-nested-type ambiguity, so dots inside Type always mean nesting. docs/publicization-semantics.md has the full behavior, including why the reserved qualifiers are rejected rather than ignored, and why several things that would otherwise be accepted are refused instead.

• Naming a type structurally sweeps its members; Include="Asm:N.T" still publicizes only the type. Deliberate divergence, and what retires the wart that "all members of one type" was regex-only.
• A colon-form DoNotPublicize on a type outranks every scope, because that form's behavior is frozen. An assembly-wide DoNotPublicize does not: it is the loosest scope there is, so a scope naming part of the assembly is more specific and carves an exception out of it. That matches the carve-out a colon-form member target has always had over an assembly deny, so the answer no longer depends on which syntax spelled an equally specific target, and "deny the assembly except namespace N" stays expressible. The composition hazard that argues for a veto — a shared .props denies, a consumer reopens — is not specific to scopes and is not fixable by one, since the colon form leaks the same way; it is reported as a warning instead.
• The characterization and signature-closure suites are unmodified, which is the evidence that moving sweep settings from assembly-global to per-scope preserved behavior.
• Fixes a latent bug: Hasher did not cover the new scopes, so two different Type targets would have shared a cache entry. The colon-form sets have a second collision of the same shape, tracked separately — fixing that one invalidates every existing cache entry, so it does not belong here.
• SweepSettings and PublicizeScope are init-only, since one SweepSettings is resolved per scope and then shared by every type that scope covers. That needs an IsExternalInit polyfill on netstandard2.0; the net10.0 test projects bind their own through InternalsVisibleTo without ambiguity.

Three things are refused rather than resolved, on the same principle: anything this form accepts now, it accepts forever, and any semantics it leaves observable-but-undecided gets depended on.

• MemberPattern on a scope. The regex matches dnlib's reflection name — + for nesting, `2 for arity — which is the exact spelling Type refuses in the same item, so honoring it on a scope would freeze that spelling in a second place and recreate the two-spellings fork one level down. The assembly-level pattern is unchanged and still applies inside every scope, and it is already slated for re-anchoring or removal; extending it here would only widen what that has to migrate.
• A scope nested in another scope that leaves one of its filters unset. Whether it should inherit from the enclosing scope or from the assembly is genuinely open, and the two readings differ only in which members end up public — so choosing now and changing later would silently rewrite working builds, with no error and no warning. Setting the filter explicitly on the inner scope costs one attribute and keeps both answers available. Assembly-to-scope inheritance is unaffected; that one is decided and pinned.
• A nameless type argument, as in Pair{,}. Only the count is read today, so it would work, but the names are reserved for Parameters and tightening this once they mean something would break items that build now.

No README yet. The syntax is only half-landed until member-level metadata arrives, and documenting it now would mean shipping a contract that has to explain what it cannot do. Note this makes the release, not the README, the point where these semantics freeze — worth deciding deliberately before this ships in one.