Operator overload refactor via re-entrant threads, list operator overload improvement

[PJB3005]

Operator overloads were extremely complex because they are calling user procs. This meant that operator overloads had to be "tail called" at the end of an opcode handler, so that we could return ProcStatus.Called.

This posed a huge problem, as the opcode handler loses control after the user proc is executed. This causes multiple issues:

• Some operator overload logic had to implemented with a special AssignRefProcState, so we could properly handle the return value of the operator overload. Yuck.
• The code surrounding this was generally spaghetti, as calling an operator overload had different stack behavior, and we have to pass ProcStatus around the place.
• It was outright impossible to implement operator[]() properly, as it would always need to be called from the start of an opcode handler.

This however is all fixable with the following revelation: operator overloads in BYOND are implicitly waitfor = FALSE. This means that if we can simply call the proc without needing to use ProcStatus.Called, we can just immediately get the return value from it.

This commit does that: DreamThread now allows re-entrantly resuming with a new call stack proc, right from the opcode handler. This means operator overloads can just be details that immediately return a value.

With this power I was able to clean all of the above issues up. The code is cleaner and less complex. operator[]() and operator[]=() work. Adding new operator overloads in the future should be easier.

[ike709]

Partially addresses #1854