feat: add native RtL css support

[XavierDefontaine]

Why

It was decided the I18nManager.forceRtL(true) does nothing on Web, hence rendering RtL handling between native/non-native very difficult using properties like margin-left/margin-right (mobile flips whereas web doesn't).

With this change, we can write RtL sensitive properties that will work across native (i.e. Mobile) and non-native (i.e. Web) platforms and allow for the components be re-used with the same strategy (more on that below) since RN does not understand marginInlineStart for example.

<HeadingContainer style={{ marginInlineStart: 10, start: 5}}>

Proposition

This PR would essentially allows us to write non-native css properties like so:

const HeadingContainer = styled.View`
  margin-inline-start: 20;
  inset-inline-start: 5 ;
`;

which would in turn be converted to accepted native css and applied like so:

<HeadingContainer style={{ marginStart: 10, start: 5}}>

It is worth nothing that this works without any code change but is less than ideal suggestion to mix native with non-native css:

const HeadingContainer = styled.View`
  margin-start: 20;
  start: 5 ;
`;

Strategy

• For Web, it is then possible to set RtL on RtL sensitive css by applying dir="rtl" on a highest top level RN parent in the tree which will force all children to take on rtl.
• On mobile, continue using I18nManager.forceRtL(true)

Notes

Minimal code change/tests since the root issue is still be discussed

[jacobp100]

Can you run prettier on this file?

[jacobp100]

Prettier again

[jacobp100]

Suggested change

	return cssRtLToNativeCamelized[propName] || camelizeStyleName(propName)
	return cssRtLToNativeCamelized[propName] ?? camelizeStyleName(propName)

[jacobp100]

The spec for this isn't yet a candidate recommendation - https://www.w3.org/TR/css-logical-1/

I'm fine to merge this if we add a note to the readme saying it's not considered stable, and behaviour may change without a major version bump