Check if we should implement `Pages` & `Attributes` for `OutputBuiltinRunner`

[fmoletta]

The cairo-lang implementation of OutputBuiltinRunner contains the pages and attributes fields, which are created via the add_page & add_attribute methods. These methods are not used during normal execution and are only used by os hints. While running os hints is outside the scope of the vm these methods would be needed for an OsSyscallHintProcessor to implement those hints. The data on these fields is also used when creating a cairo pie.

Adding this behaviour would entail:

• Creating the pages and attributes fields in the OutputBuiltinRunner
• Implementing the methods add_page & add_attribute for OutputBuiltinRunner
• Implementing OutputBuiltinRunner.finalize_segments (This would add the logic of pages and attributes on top of the common builtin segment finalization)

[Oppen]

I would suggest converting the BuiltinRunner back into a trait. It was my mistake to think converting to enum was the only way to make it Sync + Send at the time due to lack of knowledge at the time. If we make it a trait, I think we can simply handle it as a different builtin in SiR with its own extra methods/fields that the OsSyscallHintProcessor will know about and use. Does this make sense to you?

[fmoletta]

I don't think adding an alternative output builtin is a good solution. These fields are part of the original `OutputBuiltinRunner', we just didn't implement them because they weren't used. This would be a small extension of the builtin's functionality, not a breaking change in the builtin's behaviour, so it doesn't really merit possibly breaking changes in how the runner interprets builtins (as this is currently a closed behaviour, not something extensible/customizable).

[fmoletta]

Implemented by #1580