Consider renaming of the macro components

[timofei-iatsenko]

Extracted from here

I believe the initial idea for macro was a "subset" of the original params from runtime versions (as original author said). So they signatures originally had to match to each other.

But since then react/js ecosystem shifted towards typescript and quality typings and high type safety become a more valuable than ever. That resulted in changes in lingui, where runtime and macro version got they own typings with different signatures to highlight for developers different usages of macro/runtime versions.

So now we have Trans from /react and /Trans from macro which are diffrent components. This PR will add useLingui from /macro in additional to /react.
This is indeed confusing. It's also confusing for IDEs, they can automatically add import to incorrect symbol and user may spend hours to understand why it doesn't work as expected.

I think, maybe it's time to change the naming to something more explicit?

Trans / TransM and useLingui / useLinguiM

The Plural, Select and SelectOrdinal don't have runtime counterparts, they are transpiled to Trans, but i believe they should be renamed to follow the same naming convention:

PluralM SelectM and SelectOrdinalM

What do you think? What would be a better name for Macro version? Do you think this is worth the discussion, or it's fine how it is right now?

[andrii-bodnar]

I was thinking about renaming the macro Trans -> trans. These M suffixes don't feel well.

Still don't have a good idea about the useLingui naming.

[timofei-iatsenko]

I saw this particular pattern with some react libs when they transitioned to functional components and created OverlayView and OverlayViewF, Polyline and PolylineF.

I actually OK with current naming, wanted to gather more feedback from people.

[cwhenderson20]

I was thinking about renaming the macro Trans -> trans

Wouldn't this break React Native support? In React Native, all components need to be Capitalized.