Or::SinglePath and Or::MultPath robustness fixes

[robhanlon22]

It's possible for left and right to be an array of messages when creating an Or::SinglePath, and it's possible for an Or::MultiPath to contain an Or::SinglePath. Adds the following fixes:

• Turn left and right into flattened arrays when constructing Or::SinglePaths, then extract one of the paths (they should all be the same). Update all methods to handle arrays of messages.
• Implement to_or on Or::SinglePath, as they may end up in Or::MultiPaths.
• Simplify Or::MultiPath.handler to just use a case statement. The hash-based dispatch was unnecessarily complex.

[flash-gordon]

Simplify Or::MultiPath.handler to just use a case statement. The hash-based dispatch was unnecessarily complex.

Now :itself.to_proc and .method(:new) are called on every call of .handler, their results should be constants instead.

[robhanlon22]

I was interested in seeing how Ruby handles this, looks like Symbol#to_proc always returns the same object:

irb(main):002:0> :itself.to_proc.equal?(:itself.to_proc)
=> true

But Object#method always returns new objects:

irb(main):004:0> Object.method(:new).equal?(Object.method(:new))
=> false

TIL 😁

[flash-gordon]

TIL 😁

I wouldn't count on Ruby too much in these aspects. They tend to tighten things a bit but it takes time. I'm pretty sure there's not much practical sense in mutable Method instances, but everything is mutable by default except for symbols and integers.