Figure out an idiom for TFOperation lifetime

[migueldeicaza]

The object is only valid as long as the TFGraph object exists, when the TFGraph goes away, the TFOperation goes away as well. So we need a way to either track all TFOperations in a TFGraph [1] or we need TFOperations to keep a pointer to the TFGraph and check if the obejct is still valid on each call, and if not zero out their handle/flag the object as useless.

[1] This is easy, provided that we never need to re-surface a TFGraph back into managed code from a native pointer, we just keep a list of all the objects created.

[Grevor]

An interesting thing to note is that this also requires all TFInput and TFOuput structs (and perhaps more I've yet seen) to know the state of the graph.

Adding a reference to TFGraph in the TFOutput/TFInput struct would break the C api compatibility. One possible solution is to separate the struct into an internal one and have them wrap that struct in turn. However, those structs would also become much larger. We also risk that the TFGraph object is kept reachable much longer than intended (may be solved with weak references, both here and in TFOperations).

All of the above assumes we allow binary-breaking changes to the library. What is the current stance on that?

[Grevor]

@migueldeicaza I would like to "claim" this one and #14 (is that a thing in this repo?). I have ideas that seems to be working and reads well. Expect PR in a few days once I have more tests.