[MVUX] [Bindable] attribute is not considered by uno's type info generator

[dr1rrb]

Current behavior

When we generate a _ViewModelwe are [adding a[BindableAttribute]`](https://github.com/unoplatform/uno.extensions/blob/main/src/Uno.Extensions.Reactive.Generator/Bindables/ViewModelGenTool_3.cs#L101). This attribute should be considered by the bindable type provider generator to generate the type info for bindings.

However it seems it's not : #2515 (comment)

Expected behavior

_ View models_ generated by MVUX should be binding friendly!

How to reproduce it (as minimally and precisely as possible)

cf. #2515 (comment)

[dr1rrb]

Note: AN hypothesis would also be that MVUX's generator is executed after uno's type info generator.

[DevTKSS]

Looked this up while investigating logging of navigation to see in first instance, at which event the DataContext of my MainPage will be set correctly and why my Content of MainPage (NavigationView) is everytime kind of broken after HotReload.

1. Which particular attribute is the correct one to set on MainPage Codebehind class, for the MetadataProvider Line in DebugConsole? Would say that would be the Reactive.Bindable.BindableAttrubute, !But! I dont think so because in the intellisense is stated it is meant for the viewModel which is not equal to the view itself.
2. The MainPage seems to get called twice? No idea why that should be done. First one after FrameNavigator via default Route, thats alright! But then the strange part beginns: all Controls which I did name with x:Name are popping up The DepencyProperty [...] is not defined in MainPage which makes me curious why it should even expect this to be a DependencyProperty? Maybe the MainPage_.... Partial generated Class from Microsoft Generator Analyzer is also delayed as imagined for the ViewModel Class?
3. Looked up also the generated MetaDataTypeProvider (or similar named, you know which one i am meaning) which should hold the links and types from model and Viewmodel. This is looking fine as expected, so I would also vote here for delayed.

BUT!
4. Given that thought, is it possible that HotReload is missing some reload action which would re-insert the needed DataContext? To replicate, do a simple uno mvux application incl. Navigator Extension add a nav-item and e.g. contentcontrol with uen:Region.Attached + uen:Region.Navigator="Visibility" like its told in the docs.
The current page will be invisible after HotReload (with changed something on mainpage like adding a textblock somewhere)
The Navigator is expected at this point to navigate at least to default Route and this would be this current page! Not one line of the logger set to trace is telling about DataContext to be set before Initialization of the Bindings of this page.
If you set this.DataContextChanged += (s,e) => this.DataContext = (MainViewModel)e.newValue you will be greeted at runtime with a InvalidCastException, which is telling you would try to Case ShellModel into MainViewModel. Speaking also for wrong timing or non-optimal Navigation Routing not looking for that type its going to at this moment. Can someone tell where exactly this navigator is expected to set this DataContext to check this? Because if this also not know this types, just silencing that warning, it would have to be fixed there also.

Idea for that Binding of viewModel in general... Could we check if it is possible to do a extension for the Page partial class generated currently from Microsoft Generator, move it for Reactive generated ViewModel to same analyser (possible that could help with initial issue also? More control and so on?) and if the user is applying x:Bind in main instance of SomePage.xaml (using Binding would tell me, he dont cares about performance, so that sourcegen stepping in would not be needed) the generator which should already knowing about the ViewModel he has to bind that View to, at least if also navigation extension with routes is used! Could add a property ViewModel or _vm or whatever you prefer in sourcegenerators to that generated class? Even if we can not tell a sourcegenerator from the Roslyn issue to depend on other generators, could we opt 1 depend on uno own generators? Opt.2 setup the correct bound and correctly updated on ViewModel changed in there? That would be at least a little step forward and for me who only read the ViewModelSourceGen code in the repo that sounds at least imaginable...