We should error on Output field usage in DAG/Steps

[elliotgunton]

Output is not mandated but you can e.g. set result or exit_code on it which should probably be an error within a DAG/Steps function.

Originally from #1162

[elliotgunton]

This may need something like https://github.com/pwwang/python-varname or https://github.com/alexmojaki/sorcery, or just a stack inspection mechanism to see if the function context is a dag/step-decorated function. We cannot simply check the _context is DAG or Steps, i.e.

        if "result" in kwargs or "exit_code" in kwargs and isinstance(_context, (DAG, Steps)):
            raise SyntaxError("Cannot use `result` or `exit_code` in dag or steps decorator functions.")

in

hera/src/hera/workflows/io/_io_mixins.py

Lines 169 to 174 in 7b7a8c7

	def __init__(self, /, **kwargs):
	if _context.declaring:
	# Return in order to skip validation of `construct`ed instance
	return
	super().__init__(**kwargs)

As there will be script function calls where Output(result="foo") is valid, but the _context is still DAG/Steps.

Slightly more complex, so will leave out of #1221 and come back to this. Also it's more of an enhancement than a bug fix

[elliotgunton]

Actually, overcomplicating it for a basic fix - we can just check if result or exit_code are set in the object that the function return when constructing the dag, but we won't be able to raise an error on the line where the result or exit_code is set

[alicederyn]

We can have a separate validation flag in the context, and disable it temporarily in our script decorators?

[elliotgunton]

I don't think it's worth overcomplicating the codebase for now for a niche error case - the error text added in 5b56891 makes it obvious enough IMO