Skipping an @implements can cause misoptimization with typed optimizations

[evmar]

In some cases we back off from emitting an "@implements" tag. But with typed optimizations, every "@implements" is potentially load-bearing.

At the TS level, every "implements" is always optional. At the Closure level, it is dangerous to ever leave out an "@implements". We have no good user-facing way of reconciling these two.

I think we should instead say something like: if you ever write "implements" in TS, we always emit an "@implements", and if the latter fails for some reason you should delete the "implements" from the TS side.

[evmar]

After some work in this area, I now better understand all the cases here.

1. if the symbol comes from Clutz? then we should emit (<- this change)
2. if the symbol is a TS builtin? then it probably exists in Clousure and we can emit it
3. if the symbol comes from a user-written d.ts, then we can probably(?) emit it with name mangling
4. if the symbol comes from a tsickle-transpiled file, then we can probably emit it with name mangling, possibly depending on whether namespaces are involved or not

Note that fixing #2 ends up triggering conformance because there's an Angular type that extends Window and by using that indirection people were calling unsafe window functions.

An approach to #4 that includes #2 are in #1077 but that was taking the wrong approach and triggered the problems in #2 and got #3 wrong I think.