refactor(store) used variadic tuple types for createSelector

[david-shortman]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/ngrx/platform/blob/master/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
• Documentation has been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[x] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[x] Other... Please describe: Technically this allows for typed selectors with more than 8 input selectors, so it's kinda a "feature" upgrade as well.

What is the current behavior?

Types were manually created for set numbers of arguments.

Partially completes #2715

What is the new behavior?

createSelector stays strongly typed for an infinite number of arguments.

Does this PR introduce a breaking change?

[ ] Yes
[x] No

[ngrxbot]

Preview docs changes for 9c16f81 at https://previews.ngrx.io/pr2905-9c16f81e/

[david-shortman]

opening as a draft to request help

[david-shortman]

Some notes:

• The TS 4.2 beta is required for the tuple types to work properly. This is due to the update for leading and middle rest elements in tuple types.
• This is currently a breaking change, as the type is much stricter than before. For instance, the selector.spec.ts file in this repo was using jasmine.Spy functions for many selectors, which cannot now be interpreted properly without a type assertion
  • Am looking for feedback on this to know what the typical route is for breaking changes. Here, if we introduce a loose overload that accepts any type for the parameters, then the usefulness of the other overloads is greatly reduced.

[david-shortman]

The old definition of selectors with props specified that all input selectors had those props, but that doesn't quite make sense to me. Couldn't they be any arbitrary selectors, and the Props are merely inferred from the projector?

[david-shortman]

Waiting on Angular to support TS 4.2 before continuing

[brandonroberts]

Let's revisit this after TS 4.2 lands in Angular