Gracefully handle control dependencies in Eager enviroments

[rnett]

Currently, calling withControlDependencies in Eager mode will cause an exception when the op is build. Ideally, this wouldn't be called at all, as it does nothing: if you have a Operand to pass into it, it has already been calculated. However, when writing code that should work in eager or graph mode (like tensorflow-framework) having to check for this every time you want to add a control dependency is annoying and currently doesn't seem to be done. Semantically, using a control dependency in eager mode is a no-op.

I'd propose making EagerOperationBuilder.addControlInput a no-op instead of throwing an exception for the reasons above. This could also be handled in the Scope methods if you don't want to change EagerOperationBuilder for some reason. I can handle the PR if this is approved.

[karllessard]

Hi @rnett , I like the idea of the no-op, because basically like you explain, even if it is useless to call withControlDependencies on a eager session, it is implicitly guaranteed that the passed operands are executed before the targeted one. So the behavior for both type of sessions is the semantically the same.