Improove Design tokens and theming

[jembach]

Hey 🤓

I'm started using native-base in small projects with minimal design customizations. Now I started working on a bigger project from scratch with a complete custom design provided by designers. Starting implementing them I figured out some inconsistency and undocumented patterns in native-base.

1. Utility types and theme customization inconsistently refers design tokens

native-base preferred refers to the design tokens which is great and should not be changed. Sometimes this behavior is not ideal for developing because not every design token should be defined. Therefore I found a great solution for that in your code here. When using { height: "2px" } the height could be explicitly set.
In my opinion this has two problems:

1. This behavior isn't documented. This makes it difficult for new native-base users to adapt. A documentation will solve this problem.
2. For size like height e.g. it is very strange to define them in this format. One possible and obvious solution for reading the code would be passing these values as numbers instead of using 2px. This is especially better when using computed sizes, where currently we have to use string literals.
   This will in addition clean the lookup much more, because currently passing height="2" and height={2} will result in the same output.
   It can be simply solved but will cause a breaking change. This is one of the reasons why I'm starting at first a discussion before suggestion PR.

2. Inconsistence in the design system props

After studying the native-base default theme configurations I liked the concept of using variant, colorScheme and size. So I started using them too which cleaned up the code very well. But then I came across that not all components can take profit of them like the FormControl.Label which typescript definition doesn't allow them to pass. There exists some more components that doesn't allow these props.
A possible solution for this can be an implementation of an interface that every component must implement.

3. The utility types order should be documented

One missing documentation part is the SPREAD_PROP_SPECIFICITY_ORDER defined (https://github.com/GeekyAnts/NativeBase/blob/a88ec164cdd7080f67975339ec40f2630e9e1995/src/hooks/useThemeProps/usePropsResolution.tsx#L17)[here]. It took me very long to figured out why my custom theme styles aren't applied to the components. One problem is the order in which they are applied. Without knowing this it will be assumed that writing {p:2} in the custom theme will replace {padding:2} in the default theme. But this isn't the case. What is much more the problem is that the documentation is telling not the truth.

This follows React Native's specificity precedence while applying utility style props to a component, order does not matter

This is from your docs page (https://docs.nativebase.io/utility-props-specificity)[Utility Props Specificity]

The solution for this is an improved documentation about the utility types.

Conclusion

I think there should be more investigated in the docs about core concepts of native-base. The components docs are perfect and for them I like native-base so much. But when diving deeper into native-base there are some missing docs.

In addition point 1 and 2 needs to have some time investing in coding. I like native-base a lot that is why I would implement the missing parts. But I would like to discuss the ways to go at first, so the PR will not be rejected.

Thank you for developing native-base 🚀