chore(*): silence ng-closure-runner warnings during grunt minall

[gkalpak]

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Chore/Refactor.

What is the current behavior? (You can also link to an open issue here)
During the grunt minall task, ng-closure-runner logs some warnings due to:

1. Throwing errors that do not seem to be minErr instances.
2. A @this annotation in a non-JSDoc comment.

What is the new behavior (if this is a feature change)?
No warnings during grunt minall.

Does this PR introduce a breaking change?
No.

Please check if the PR fulfills these requirements

• The commit message follows our guidelines: https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit-message-format
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

[gkalpak]

I am not thrilled about having to pass the first two string arguments.
Alternatively, we could teach ng-closure-runner to ignore noMinErr instances (i.e. not treat them as minErr instances, but don't log a warning either).

[gkalpak]

For reference:

Before

Running "minall" task
...
build/angular.js:5038: WARNING - Throw expression is not a minErr instance.
          throw err;
          ^
build/angular.js:8763: WARNING - Throw expression is not a minErr instance.
            throw errors;
            ^
build/angular.js:12860: WARNING - Throw expression is not a minErr instance.
            throw e;
            ^
build/angular.js:14531: WARNING - Throw expression is not a minErr instance.
        throw e;
        ^
build/angular.js:18772: WARNING - Throw expression is not a minErr instance.
            throw e;
            ^
build/angular.js:30307: WARNING - Parse error. Non-JSDoc comment has annotations. Did you mean to start it with '/**'?
    forEach(options, /* @this */ function(option, key) {
                     ^
0 error(s), 6 warning(s)
>> build/angular.js minified into build/angular.min.js
...

After

Running "minall" task
...
>> build/angular.js minified into build/angular.min.js
...

[petebacondarwin]

Did you check whether this ends up creating no error pages in the docs?

[gkalpak]

No 😕

[gkalpak]

AFAICT, it does not. It does create a no: {'': ''} entry in build/errors.json, but as long as there is no corresponding error doc, no entry is created in nav-data.json.

[petebacondarwin]

That is true but you now get this in the build:

warn:    No error doc exists for min error: no:

[gkalpak]

Irony 😒
This is still better than what we get today (and I am sure we can silence that warning 😈).
The main question is: Do we like this approach?

[petebacondarwin]

Given that we are then creating workarounds for workarounds, I start to feel that it would be better to fix the ng-closure-runner tool instead. It could simply be a comment flag (or other device) to tell minerr to ignore that error throw.

[gkalpak]

As discussed, it doesn't make sense to fix it in ng-closure-runner at this point.
I moved the jsdoc comment fix to #16575.