Add lint for protecting people from accidental infinite loops / infinite revalidation errors

[NullVoxPopuli]

Coming out of:

• https://github.com/NullVoxPopuli/ember-resources/issues/340
• and https://github.com/emberjs/rfcs/issues/769

I think we should add a lint rule in certain places known to cause issues with infinite looping

For example, in ember-concurrency tasks, if you don't yield Promise.resolve() or await Promise.resolve() (depending on your ember-concurrency syntax), you'll get the infinite revalidation error (or infinite loop).

This only happens when using concurrency tasks as derived data, such as what ember-resources encourages.

But concurrency tasks aren't the only place where this can happen -- could be in plain functions, helpers, or modifiers as well. Esp as https://github.com/emberjs/rfcs/pull/756 and https://github.com/emberjs/rfcs/pull/757 are implemented.

Maybe it's something we need to work with the typed-ember folks to figure out, because some of this depends on how stuff is used in the template. Like, eslint can't possible know if a function is going to be a helper or modifier

[NullVoxPopuli]

cc @dfreeman @chriskrycho ?

[NullVoxPopuli]

I think maybe this could only be possible as a type-aware lint rule, and only for types of tracked-data which are not @tracked properties (as, to TS, they are just their value).