Add Op registration to symbol table inside OpBuilder

[lima-limon-inc]

Closes issue number 404

Currently, building an operation and adding it to a symbol table are done separately. This PR makes operation insertion into a symbol table happen inside the Operation Builder, thus encapsulating it with Operation creation.

To enable it, a new trait BelongsInSymbolTable was created. Operations that have this trait are going to be stored inside the symbol table of a different operation.

This meant that these operations needed a reference to their parent's symbol table at operation creation. To support this,
a new OpCreateParamTypevariant was created called BuildOnlyParameter. This is used for arguments that are only used in the Operation::creation and OperationBuilder functions, in this case a reference to the caller'sSymbolTable.

Besides the addition of a new function parameter, the #[operation] macro was expanded to handle Symbol Table insertion.

Originally, Operations were built, verified and returned inside the BuildOp::to_tokens macro.
However, adding conditional symbol-table insertion made the macro a bit too convoluted (see here).
So in order to make the flow more consistent and easier to follow, I went for splitting the macro up into 3 different stages:
BuildOp, ModifyOp and ReturnOp

• BuildOp was basically unchanged. The only change was that it now doesn't return the built op, it only builds it and stores it in a variable.
• ModifyOp was created and is the place where the conditional symbol-table insertion logic resides. This is also "extensible", other post-build functions can be inserted inside it and should be able to simply "chain" their functionality. It can be seen as a "post build hook".
• ResultOp: This last macro is simply in charge of returning the op. I added an #[allow(dead_code)] simply to keep all the *Op macros in the same format

[lima-limon-inc]

Not used currently, left just in case

[lima-limon-inc]

These tests got updated because now they contain a WorldBuilder which wasn't there before. The only thing that (should)'ve changed is the block number (which increased by one).

[lima-limon-inc]

Edit: I removed the struct SymbolTableHolder in favor of the already present World. It added a too much import related complexity for the little value it added.