add accessibility and testId props and virtual nodes to support e2e tests tools

[toter3]

note: this is a duplicate for a PR authored by @galkahana that could not be merged due to technical reasons

Summary

we use clickable Svg elements in our app and in order to test it, there is a need for testId / accessibility desc attributes in native elements, so it could be use with tests selectors.

To fix this I added accessiblity Info to all SVG elements (via VirtualView and SvgView).

specifically the following properties of AccessibilityNodeInfo are set:

setBoundsInScreen - This is used by accessibility readers to determine the position and dimensions of an element. For Appium it determines the clickable/visible area of the element.
setVisibleToUser - A boolean flag that determines whether an element is visible at all to the user. For appium it determines whether this elements is visible at all in the tree hierarchy.
setClassName - This one provides a name for the class to be visible in the tree hierarchy. If not set it uses a default android.view.ViewGroup. By setting the class name it's much easier to find your way in the tree. This is not required for a minimal solution for Appium, but it helps a lot.

example with screenshots of before and after the change to demonstrate:

here Im adding accessibilityLabel and testID props to the circles in the group in the example app (examples/G.txs: 24):

      <Svg height="100" width="100">
        <G fill={this.state.fill} stroke="pink" strokeWidth="3">
          <Circle cx="25" cy="25" r="11" accessibilityLabel={'first circle'} testID={'first-circle'}/>
          <Circle cx="25" cy="75" r="11" stroke="red" accessibilityLabel={'second circle'} testID={'second-circle'}/>
          <Circle cx="50" cy="50" r="11" fill="green" accessibilityLabel={'third circle'} testID={'third-circle'}/>
          <Circle cx="75" cy="25" r="11" stroke="red" accessibilityLabel={'fourth circle'} testID={'fourth-circle'}/>
          <Circle cx="75" cy="75" r="11" />
        </G>
      </Svg>

and here is how it looks when inspecting the elements:

before the change:

after change:

(notice before the change the ViewGroup does not have children, and with the change it has children with the accessibility and testId atrrs)

Test Plan

Test Plan
To test you can use Appium inspector and appium server gui and see that setting the props makes the relevant props visible, in a similar manner to plain RN views. e.g. "content-description" would be set for "accessibiltyLabel" in android. "testID" would map the "name" in IOS.

For detox or selenuim, in particular in Android, where it is different from Appium, it is possible to write a basic test in detox and run it.

What's required for testing (prerequisites)?
you will want detox and appium setups. and some basic tests.

What are the steps to reproduce (after prerequisites)?
For appium, best is to just view the relevant properties (testID and accessibilityLabel) in Appium desktop.

For detox, running a test successfully will work.

Compatibility

OS	Implemented
iOS	✅
Android	✅

Checklist

• I have tested this on a device and a simulator
• I added documentation in README.md
• I updated the typed files (typescript)
• I added a test for the API in the __tests__ folder

[WoLewicki]

@toter3 isn't this PR a duplicate of #1372 or does it add something new?

[toter3]

@WoLewicki yes this is almost identical, I actually didn't see this one, i saw another PR Gal opened from the company's user i think, and it was missing some stuff.

anyway since it wasn't merged and a lot of versions changed since, maybe it'll be easier to merge this one.
but tell me what you think.

[WoLewicki]

In general, it's not good to merge duplicate PRs, as it can be considered unfair to the original author. The problem is that I asked for a rebase to the latest main more than half a year ago, and @galkahana doesn't seem to have responded at all. Therefore, I will merge this PR, but add a note that @galkahana is the original author.

[toter3]

will do, thanks!

[WoLewicki]

I added some comments about the code, but other than that, it seems just fine! I will change those in another PR. Thanks for your contribution!

[WoLewicki]

What about accessibilityLabel prop?

[WoLewicki]

Since the types for those are already string/boolean, I think we don't need to do String(x) or Boolean(x).

[maxkomarychev]

thanks @toter3 and @WoLewicki !!

[maxkomarychev]

and @galkahana :)