Entry keyboard handler

[bkaankose]

GitHub closed the PR. Re-opened at #682

Description of Change

Implements #380

Additions made

• Adds Keyboard property to ITextInput interface.
• Adds Keyboard bindable property to Entry (derived from InputView)
• Adds KeyboardExtensions for iOS and Android Platforms.
• Adds LocalizedDigitsKeyListener to Android platform to support localized decimal separator. (This was overridable with renderer architecture. Similar approach is not implemented in this PR.)
• UpdateKeyboard mapper for Entry's PropertyMapper.
• Mapping extensions for EntryExtensions for both iOS and Android. Additionally for Android, setting native element property count (EditText.InputType) is reduced to 1 as mentioned here Implement IsTextPredictionEnabled in IEntry Handlers #423 by @mattleibow
• Implements Numeric type keyboard to Sample app with placeholder 'Numeric Entry'.
• Updates EntryStub with Keyboard property (Default=Keyboard.Defaullt).
• Implements device tests for both iOS and Android for all non-custom type Keyboard types.
• Adds {KeyboardType}KeyboardClassData objects for xUnit to handle ClassData for non-custom type keyboard types since Keyboard is not an enum but Keyboard instances.

Notes

• We don't have Element.IsSet implemented yet from the old renderer architecture. On Android, since IsTextPredictionEnabled also updates the keyboard input type, handler doesn't check for whether it's value has been set or default. Because of this, MapKeyboard mapper must be called before everything else to prevent unwanted behaviors. I don't know what's the proper change here. Open for suggestions.
• As I mentioned on the Additions Made section, LocalizedDigitKeyListener is not overridable at the moment like it used to. Open for suggestions
• I am not %100 sure whether some of the files I add are in correct folder-file structure like KeyboardExtensions, LocalizedDigitKeyListener and KeyboardClassData. I'll be grateful if maintainers guide me or move them to propriate places.

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

[mattleibow]

Thanks for the PR. Looks good.

Just got a few suggestions of maybe moving the code from Compatibility if we are using it instead of copying.

[mattleibow]

Was this never here before? Do we really need to add this for derived controls @PureWeen?

[mattleibow]

Why is this only when not a custom keyboard?Do we expect the keyboard to override this property?

[mattleibow]

With regards to the override-ability, we can currently do that by just doing something like this:

EntryHandler.EntryMapper[nameof(IEntry.IsReadOnly)] = (EntryHandler handler, IEntry entry) =>
{
	// do things before ...

	// optionally call "base" implementation
	EntryHandler.MapIsReadOnly(handler, entry);

	// do things after ...
};

This is effectively the "renderer" and "effect" combined.

[mattleibow]

Looks good!

[mattleibow]

Huh? Why did this close after merging 😭

[mattleibow]

This one auto changed... #589 (comment)