Broken attached property detection with `AddOwner` usage

Describe the bug After recent text processing changes TextBlock attached properties have been moved to TextElement. One would expect that old code using TextBlock properties will fail to compile so it can be fixed. But this is not the case and many invalid usages work fine.

To Reproduce

<Window.Styles>
  <Style Selector="ContentPresenter">
    <Setter Property="TextBlock.FontWeight" Value="Normal" />
  </Style>
</Window.Styles>
  
<StackPanel>
  <ContentPresenter TextBlock.FontWeight="{DynamicResource ComboBoxHeaderThemeFontWeight}" />
  <ContentPresenter TextBlock.FontWeight="Normal" />
</StackPanel>

Usage in style setter - works fine Usage with a dynamic resource or binding - works fine Usage with a raw value - compilation error

Expected behavior I would expect all cases above to error out since this is no longer an attached property (not sure about selector though) on TextBlock.

After a quick check in the compiler it seems that this property is detected as an attached property since property type name does not contain Attached. https://github.com/AvaloniaUI/Avalonia/blob/master/src/Markup/Avalonia.Markup.Xaml.Loader/CompilerExtensions/Transformers/AvaloniaXamlIlTransformInstanceAttachedProperties.cs#L45

AddOwner on an attached property is supposed to convert it to a regular styled property I think but since property analysis is static it is not picked up. But even in runtime one cannot tell if this a converted attached property since original attached property is returned. https://github.com/AvaloniaUI/Avalonia/blob/master/src/Avalonia.Base/AttachedProperty.cs#L39

I think that user code will struggle a lot with random compilation errors caused by text breaking change until this issue gets resolved.

[MarchingCube]

My worry is coming from that my project has tons of code like:

This seems to work for now. Now somebody changes one value to a non-binding.

And you get an interesting error message:

Which claims that one cannot set FontSize on a TextBlock.

[grokys]

Spoken privately with @MarchingCube and this problem was caused by referencing a stale assembly. Keeping the issue open though because in investigating the problem I found a slight discrepancy on how attached properties are resolved. PR incoming.