Consolidate handlertestbase

[PureWeen]

Description of Change

• Currently our FrameRenderer doesn't call any of the initial mapper properties that run through the batch update. All of the tests for this behavior currently exists inside Core.DeviceTest on the base handler. The intent of this PR is to move all of that testing code into a re-usable place so that FrameRenderer (and other handlers inside Controls) can utilize the tests we have in Core.DeviceTest to validate that all the default ViewHandler mappers. This PR also consolidates a bunch of helper methods that were duplicated between Core/Controls

• I moved all of the code shared between Controls/Core.DeviceTests to Core.DeviceTests.Shared. These don't seem like things we'd ever really package up and distribute. They are a bit specific to our tests. Anything we'd want to package up we should move to TestUtils and AssertionExtensions

• I tried to rename anything that was a repeated class name. So, now there's only one HandlerTestBase, ContextStubBase, etc..

• This PR doesn't actually fix Frame yet it's mainly just the reorg part of the tests so that I can fix Frame and add tests here https://github.com/dotnet/maui/pull/10751/files#diff-ad087c312304a6bb9d0b8d53ab57e6d941c1fa937885ad9f10922b1734f2f0d0R118

• Moved all the ITextStyle tests out of HandlerTestBase and into a specific TextStyleHandlerBase so now instead of just having a bunch of noop tests related to TextStyle they all just run for interfaces that implement ITextStyle

[PureWeen]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[hartez]

A few questions.

[PureWeen]

Moved these all into TextStyleHandlerTests since they apply to anything that implements ITextStyle

[Eilon]

Looks good for the BlazorWebView device test changes.

[PureWeen]

@hartez I added this code because all of the ScrollView tests started failing due to view.Measure returning infinite size.

I'm wondering if this is actually a bug with ScrollViewHandler.

The GetDesiredSize code inside ScrollViewHandler just returns the constraints back if the ScrollView has no content (which makes sense)

https://github.com/dotnet/maui/blob/main/src/Core/src/Handlers/ScrollView/ScrollViewHandler.iOS.cs#L226-L229

I wonder if for this scenario the ScrollViewHandler on iOS should return a size of zero if the content is null and the constraints are infinite.

Something like

if (platformView == null || virtualView == null || virtualView.PresentedContent == null)
{
     if (double.IsPositiveInfinity(widthConstraint))
          widthConstraint = 0;
          
     if (double.IsPositiveInfinity(heightConstraint))
          heightConstraint= 0;
          
     return new Size(widthConstraint, heightConstraint);
}

If this does seem like something we should fix on ScrollViewHandler I'll do that in a different PR. I'd like this PR to not touch any actual sdk code just test code.

[hartez]

/backport to net7.0

[github-actions]

Started backporting to net7.0: https://github.com/dotnet/maui/actions/runs/3489791409