Translating WinUI elements to LiveView

Nobody has claimed this yet.

One thing we have to establish early will be the syntax of WinUI elements in templates. For example, this is valid WinUI3 markup:

```html

```

In LiveView any elements with `.` notation are parsed as function calls on that module name. So `Grid.RowDefinition` will cause issues. There are a few paths that we should explore:

1. Converting everything to LVN functions. This would the heaviest lift because we would have to provide a LVN component for each and every element name.
2. Using an alternative syntax. `Grid:RowDefinition` would allow us to preserve most of the original element name but it does introduce a syntax that LiveView itself has not claimed yet. If in the future LiveView wanted to use the `:` syntax we'd have backwards incompatibility
3. Nesting under a namespace and update the engine to not parse the namespaced element name for function lookup. Something like: `` we could always match `WinUI3` and short-circuit the function lookup. This adds verbosity to the templates but provides a clean bottleneck
4. Update the engine to not do a function lookup if the the function name includes capitalization. If this is possible it may be the best option. For example: `Grid.RowDefinition` wouldn't attempt a lookup of `Grid.RowDefinition/1` because that function name doesn't conform to Elixir's convention of lowercase and underscored function names. We'd have to ensure there are no possible element names in WinUI3 that would match as an Elixir function

No files, tests, or entry points are named; begin by locating the LiveView element parser and the WinUI template-handling path. Compare the four syntax and function-lookup approaches described here, then document the compatibility decision; done means dotted WinUI elements can be translated without conflicting with LiveView lookup.

Written by the indexing model from the issue text.