feat(components): add ngrxPush migration

[timdeschryver]

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
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

Closes the first todo of #2450

What is the new behavior?

This PR adds a visitTemplates method to schematics-core to find all templates (inline and as a file).
For the migration, it creates a new ngrx-push-migration schematic.

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

Implementation is inspired by angular material.

[timdeschryver]

this is the most interesting part of the PR

[ngrxbot]

Preview docs changes for 5c31542 at https://previews.ngrx.io/pr2452-5c31542/

[brandonroberts]

Won't this break their existing app/tests due to missing ReactiveComponentModule imports?

[timdeschryver]

I didn't think of that, but you're right @brandonroberts !

[timdeschryver]

Some options that I think of are:

• add the ReactiveComponentModule import to every module
• make the migration configurable, the user can provide the module(s) and a path pointing to a directory (currently, the migration will recursively traverse the whole project)
• don't write this migration, because it can also be done manually with a simple find and replace

Regardless of the decision we make, I would like to ask to review the template visitor as this may be useful for future migrations?

[brandonroberts]

The template visitor code looks good to me. I don't have a strong choice on the options, as modifying all the modules is a bit heavy-handed, and if you're providing the modules to change, you might as well have added the import manually(assuming you have fine-grained modules).

[brandonroberts]

Circling back on this, we could add ReactiveComponentModule to the imports/exports anywhere CommonModule is added from @angular/core. We know that you need to have it to get the AsyncPipe, which is the thing we're replacing.

[timdeschryver]

Sorry, I forgot about this PR...

What you're saying makes sense!
It should be fairly simple to add it to this schematic.

[timdeschryver]

@brandonroberts it was also needed to check for BrowserModule