Description of Change

• Adds full implementation of ContentLayout and ImageSource to Android and iOS
• I made all the IButtonContentLayout bits internal for now. We can discuss making them public in a later PR
• This converts Android to using MaterialButton which has built in behavior for laying out the icon next to the text. Unfortunately they implement it for all three sides except for Bottom which made the implementation a bit odd
• For Android I converted our FileImageSourceHandler to use GetDrawable for now so that it returns the image at the same size as iOS. We'll reconcile all the Glide behavior in a separate PR
• Currently on XF iOS sets the image to Aspect Fit whereas android just loads the image as is. I changed this to Center on iOS so it matches Android. Currently on XF iOS if you load an image that's too large for the button it looks completely wrong. It also looks wrong in MAUI but it looks less wrong. Fixing cases where the image is too large will be part of a different PR

Known Issues

Android still has some measuring issues that need to be worked through. The buttons with images on the start/end appear to have issues when nested inside a NavigationPage. We're going to replace the NavigationPage with a better Maui.Core implementation so for now we will probably wait until that implementation is in to revisit the issues here. I did a quick test using the Android Navigation View handler branch and on that branch the layouts were all correct.

Breaking Changes

This implementation breaks iOS but makes it match with Android so now the ContentLayout behavior between iOS and Android should be identical. The ultimate fix here would be to add some additional layout position options (LeftText, RightText, TopText, BottomText) . The implementation in XF on iOS is basically LeftText, RightText, TopText, BottomText.

PR Checklist

• Targets the correct branch
• Tests are passing (or failures are unrelated)
• Targets a single property for a single control (or intertwined few properties)
• Adds the property to the appropriate interface
• Avoids any changes not essential to the handler property
• Adds the mapping to the PropertyMapper in the handler
• Adds the mapping method to the Android, iOS, and Standard aspects of the handler
• Implements the actual property updates (usually in extension methods in the Platform section of Core)
• Tags ported renderer methods with [PortHandler]
• Adds an example of the property to the sample project (MainPage)
• Adds the property to the stub class
• Implements basic property tests in DeviceTests

Does this PR touch anything that might affect accessibility?

• Does this PR introduce a new control? (If yes, add an example using SemanticProperties to the SemanticsPage)
• APIs that modify focusability?
• APIs that modify any text property on a control?
• Does this PR modify view nesting or view arrangement in anyway?
• Is there the smallest possibility that your PR will change accessibility?
• I'm not sure, please help me

If any of the above checkboxes apply to your PR, then the PR will need to provide testing to demonstrate that accessibility still works.