Allow yieldAsReturn option in conjunction with new settings.jsdoc.mode

[brettz9]

feat(require-returns-check): with settings.jsdoc.mode (typescript or gcc), allow yieldAsReturn option as "always" or "argument" to treat yield as return (fixes #271)

The mode setting--as discussed in another issues--would allow precise tweaking of behavior across other rules as well (e.g., for check-tag-names to disallow @template by default in regular jsdoc mode, but allow it with gcc). But this PR only ensures that regular jsdoc mode cannot treat yield as a return since regular jsdoc has the @yields tag which may be used for that purpose.

[golopot]

I think a better approach is to skip require-returns-check rule for all generator functions. A generator function always returns an iterator, regardless of the presence of yield statement. This approach is analogous to how we treat async functions in the rule.

[brettz9]

For jsdoc mode, I was in agreement--and I would hope TypeScript/GCC will come to support @yields to differentiate. My thinking was to allow for TypeScript/GCC just for the time-being, overloading @returns.

However, in looking at microsoft/TypeScript#23857 , I see that they already have a syntax for overloading @returns, indicating (similar to how Promises can be documented) the type yielded by the iterator, IterableIterator<Something> in the issue example. The issue mentions eslint valid-jsdoc as complaining, but that, as we know, is deprecated, and we can of course, get it to work ourselves.

So rather than skipping checking for generators, I think we should make sure that unless it is IterableIterator<void> or such (in which case just a yield might be expected), we should require yield with a value. It shouldn't be hard to adapt this PR to do this, and it'd avoid the need for the option.

[golopot]

That feature should be addressed in #354 in a separate rule.