Diagnostics / torchlib implementation consideration

[justinchuby]

1. I would avoid modifying any function signatures (e.g. adding a context parameter to torchlib functions etc.) This is because we want to preserve a natural function calling experience for users, where one can call a torchlib function the same way they would call an ATen op. We also want to ensure the function signature written is what gets generated in the ONNX graph.
   • We can consider having a call hook etc. that handles any context before and/or after going into a torchlib function (trace_only or not)
   • Related: roles of a function
2. I would also try to reduce the scope of the change needed, for us to preserve a more natural authoring experience. For example, if it is possible to change just the torch_op decorator or the OnnxFunction class or an evaluator, then I would avoid adding a new decorator to all existing torchlib functions.

cc @fatcat-z @xiaowuhu @BowenBao