Fix the parts of #2253 that still reproduce

[siegfriedpammer]

Works through the parts of #2253 that still reproduced on master, after every claim in the thread
was rebuilt and re-tested. Five of the twelve were already fixed, three are fixed here, one is
closed as not worth its cost, and one turns out not to reproduce. Verifying the result against a
real WPF application then turned up a defect nobody had reported.

-p converts BAML on its own

A WPF assembly keeps its windows and pages as BAML, so a project exported without converting them
back is missing the parts that make it a WPF application. The CLI could do it since
--decompile-baml was added, but only if asked - which meant everything the exporter knows about
WPF (Page and ApplicationDefinition items, resources, generated members removed from the
code-behind) was invisible to anyone following #2253 from the command line. The flag is kept and
ignored, because it is documented and scripted against.

A XAML parser can read the output back

Markup-extension values (claim 9) went out unquoted, so an argument carrying , = { } a
quote or a backslash was read back as further name/value pairs. This is the DevExpress
{DXBinding Expr='...'} report, and it is the only claim of the twelve whose output does not
compile. Values without such a character stay unquoted, so documents that never needed quoting are
unchanged.

Namespace declarations (claim 11) were minted on the element that used them, for namespaces the
document had already declared at its root. Two causes: a clr-namespace: declaration names the CLR
namespace it maps and nothing read that name out of the URI, so no lookup by namespace could match
the declaration the document made; and the document records the assembly it was written against
while a well-known type carries the assembly it resolves to now - mscorlib against
System.Private.CoreLib - so those are now accepted as the same when the recorded assembly
forwards the type.

A document and its code-behind share a path (claims 2 and 7)

The XAML went to the project root under a fully-qualified name while the partial class went into a
namespace directory, so the two halves of one class sat in different places and WPF tooling paired
neither; --nested-directories moved only the C# half, widening the split. Both now go through one
function that decides where a type's files live. The BAML writers of the UI and of the command line
had each grown their own copy of the naming, which is how they came to disagree with the C# writer.

What an exported application was still missing

StartupUri is written in App.xaml but never reaches the BAML: the markup compiler turns the
attribute into an assignment inside InitializeComponent, and the project decompiler deletes the
generated members, so the exported application built and opened no window. The assignment is read
back out of the generated method and written to the document root again. Where the compiler emits
no app.baml at all - an App.xaml carrying nothing but attributes - there is no document to write
it on, and the export has no ApplicationDefinition either; that is a larger gap of its own.

A CLR property called Name on a type of the assembly being decompiled was written back as the
x:Name directive. x:Name is recorded as the runtime name property of an element, which is
FrameworkElement.Name for everything WPF - a property of the framework. <local:Helper Name="h" />
therefore came back as x:Name="h": the name gets registered, the property stays unset, and it
still compiles. The directive is now written only for a name the element does not declare itself.

Two things found while verifying

A facade standing in for WindowsBase cost every WPF assembly its geometry documents. .NET ships
a WindowsBase facade on every platform: it resolves under the name BAML means, so no synthetic
stand-in was substituted, and it carries none of the WPF types because those live in the
WindowsDesktop runtime pack. System.Windows.Point and Size then resolved to nothing and the
whole resource was lost to a NullReferenceException. Ten of the BAML entries in one DevExpress
theme assembly, on every machine without WPF - which is every Linux and macOS user and every CI
run. A well-known assembly now counts as resolved only if it defines a type it is expected to have.

Item metadata in the non-SDK project format was written as attributes, which is MSBuild 15
syntax; that format exists for the toolchains that predate it. It now writes child elements, the way
every non-SDK project keeps metadata. The SDK-style writer keeps attributes.

Verification

• 30 tests in ILSpy.BamlDecompiler.Tests and 5 in ICSharpCode.ILSpyCmd.Tests, each written
  failing first. The quoting rule has nine cases; the xmlns and facade tests reproduce their
  defects from BAML records, so they need no WPF and run everywhere.
• A real DevExpress theme assembly (1168 BAML documents, from the package on nuget.org):
  output identical to master over all 1158 documents master could produce, plus the ten it used to
  lose to the facade bug.
• The application from the report. DevExpress publishes the source of
  DevExpress.StockMarketTrader.Wpf and the components it builds against are on nuget.org, so it
  can be built and its BAML compared against the XAML it came from:
  {DXBinding Expr='ThemeIndex == 0', BackExpr='0'} came back from master as
  Expr=ThemeIndex == 0, BackExpr=0 - two name/value pairs where the author wrote one - and comes
  back correct here. Its App.xaml also gets its StartupUri back, byte-identical to the source.
• A purpose-built WPF application for the two cases the demo does not cover: a class with a CLR
  property of its own called Name, and an App.xaml with a StartupUri. Both round-trip identically
  to the source now; before, one lost its property to the directive and the other lost the attribute
  entirely.
• ICSharpCode.Decompiler.Tests 3599, ILSpy.Tests 1262, ICSharpCode.ILSpyCmd.Tests 47, no
  failures.

Deliberately not done

• Attribute wrapping (claim 12). XmlWriterSettings.NewLineOnAttributes would turn this on in
  one line, but it applies to every element, so <TextBlock Text="a" /> becomes three lines too.
  Wrapping only long start tags means hand-writing the serializer - XmlWriter closes the start tag
  as soon as whitespace is written between attributes - and a hand-written writer owns attribute
  escaping, which is where this decompiler has had real bugs. Not worth it for a cosmetic
  complaint.
• Generator (claim 8). The reported replacement, XamlIntelliSenseFileGenerator, is wrong in
  both project formats: real projects of either kind write MSBuild:Compile.
• A nested tag as an attribute (claim 10). Does not reproduce. Across the twelve documents of
  the application it was reported against, no element is lost; what is there is a declaring-type
  shift (UserControl.Resources becomes FrameworkElement.Resources), which is legal and compiles.
• Reconstructing an App.xaml that was never compiled into BAML. When the markup compiler emits
  no app.baml, the export has no application definition to produce, StartupUri included. That is a
  bigger piece of work than recovering an attribute onto a document that exists.

Prepared by an AI agent (Claude, claude-opus-5, via Claude Code) and reviewed by @siegfriedpammer.