feat: adds support for new "selector" API

[ahrjarrett]

Closes #1758

This PR accompanies i18next/#2322.

What this PR changes

To keep the review of this PR simple, I figured it would help if I talked about the changes, since the actual change is quite small.

Here's a simplified version of what this PR does:

// Before
type TransProps<Key extends ParseKeys<Ns, TOpt, KPrefix>> = { 
    i18nKey?: Key | Key[];
}

// After:
type TransProps<Key> = { 
    i18nKey?: Key;
}

type GetTransProps<
    Key extends ParseKeys<Ns, TOpt, KPrefix>
> = TransProps<
        // there is one additional branch here, to decide 
        // what to pass as the translation source:
        _EnableSelector extends true
            ? SelectorFn
            : Key | Key[]
    >
>

Essentially all this PR does is adds an inline check for whether enableSelector is turned on; if so, it processes the tree of translations, rather than generation a union of strings.

Checklist

• only relevant code is changed (make a diff before you submit the PR)
• run tests npm run test
• tests are included
• commit message and code follows the Developer's Certification of Origin

Checklist (for documentation change)

• only relevant documentation part is changed (make a diff before you submit the PR)
• motivation/reason is provided
• commit message and code follows the Developer's Certification of Origin

[coveralls]

coverage: 95.797%. remained the same
when pulling 1b9d390 on ahrjarrett:selector
into 8efef93 on i18next:master.

[adrai]

Decide: how should we handle "fallback" selections, as outline in this comment?

Currently the Trans componant has this defaultValue: const defaultValue = defaults || nodeAsString || reactI18nextOptions.transEmptyNodeValue || i18nKey;

[marcalexiei]

Like I mentioned earlier, I don't have time to look at this right now—feel free to go ahead without me.

[adrai]

@VIKTORVAV99 can you also have a look at this?