Accessibility code needs forward-port to RN60 APIs

[mikehardy]

There is a related issue in #893 about some deprecated APIs, but more importantly, an API in use now is completely gone from RN59 to RN60 - RN.AccessibilityInfo.fetch()

React-Native added support for more accessibility features, and they broke the API out into multiple feature-specific APIs.

Here's the documentation update facebook/react-native-website#835

The API in use is here: https://github.com/microsoft/reactxp/blob/master/src/native-common/Accessibility.ts#L39

The corresponding API (for screen-reader only, to make ReactXP work with RN60) would be to use RN.AccessibilityInfo.isScreenReaderEnabled() and to register the listener for 'screenReaderChanged' event vs 'changed'

I will propose a PR for that specific change as ReactXP will be a breaking-change anyway so it's okay for it not to work on RN59, but future enhancements should expand the Accessibility to take advantage of the rest of the new features. If that is desired I could propose a second PR that offers complete coverage of the enhanced API though I may need some hand-holding in how to deal with iOS/Android-specific differences as parts of the API are available only on one platform or another

Cross-linking with #1123 for visibility there since I mentioned it prior.

[mikehardy]

Fixing this will be complicated by the react-native Typescript definitions being out of sync, they still have the RN59 API https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/react-native/index.d.ts#L6923

[fbartho]

Also blocked by #1053, #1039

[mikehardy]

@fbartho Worth noting that I have it working on RN60 with the exception of this Accessibility stuff, as far as I can see. I don't use all the APIs of course, but async storage isn't a problem for me after installing the react-ntaive-community component

[mikehardy]

I have re-read things @fbartho and I want to say that async-storage is not a blocker. Additionally, the deprecations you mention are not blockers, technically. They are breaking changes, but there's no reason reactxp couldn't go 2.0 with the current / currently PRd changes and function correctly, then do 3.0 with async-storage extraction and deprecation handling. I recognize this might seem pedantic but I am always very careful about release scoping and blocker designations as they affect velocity so immediately.