feat(effects-ng): prefer classes from "effects" as injection tokens

[Char2sGu]

PR Checklist

Please check if your PR fulfills the following requirements:

• [x] The commit message follows our guidelines: https://github.com/ngneat/effects/blob/master/CONTRIBUTING.md#commit
• [x] Tests for the changes have been added (for bug fixes / features)
• [x] Docs have 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?

Currently we intentionally create new tokens for providers even if the provider is an existing concept in the core package and there is an available class in the core package to use as an injection token.

This intentional design might bring some benefits, but it might be more beneficial to simply use the existing classes from the core package as injection tokens.

In most cases, the user installs both @ngneat/effects and @ngneat/effects-ng. When the user hope to inject Actions, the first option suggested by the IDE is sometimes the one from @ngneat/effects (tested in VS Code), which might cause confusing runtime injection errors as it is not easy to notice.

Besides, this also enables access to the provided EffectsManager instance, which can be quite useful when the user wants to create wrappers upon this library, as stated in #66.

Issue Number: N/A

What is the new behavior?

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

[stackblitz[bot]]

Run & review this pull request in StackBlitz Codeflow.