Add RBS::Ops

[sampersand]

[WIP]

This PR adds in RBS::Ops, a uniform location for all operator interfaces.

[sampersand]

Open questions:

1. Do we want the names to be short (_Add, _Sub, _Leq, _Neq), medium (_Add, _Subtract, _LessThanOrEqual, _NotEqual), or long (_LessThanOrEqualTo, _NotEqualTo)? I've currently picked the medium ones
2. Do we want to use math operator names like _Multiply / _Modulo, or do we want to use more use-case-agnostic ones like _Times (and what should % be in that case?)
3. I've not made interfaces for eql? or equal?, as they're not formal operators. Do we want interfaces for them here too?
4. I've not made interfaces for [] or []= as their arity can vary, and thus doesn't fit well into the type system. (Same with a _Call interface, which would be nice eventually, but has similar problems)
5. I've made heavy use of default interface arguments, eg with <=, as most of the time you just want a bool return value (but you could specify a different one if needed):

    # An interface for types implementing the `<=` operator
    interface _LessThanOrEqual[O, R = bool]
      # Perform the `<=` operation
      def <=: (O other) -> R
    end

5. (continued, i can't figure out GitHub markdown) I've left the first argument usually required (except for _Equals, _Compare, and _NotEquals where it defaults to untyped, as their signatures traditionally are). Do we want to have the O parameter default to self on most of the other operators?
6. Where and how do we want to test these interfaces? we don't historically have interface tests. Just typechecks?

[ParadoxV5]

1. Do we want the names to be short (_Add, _Sub, _Leq, _Neq), medium (_Add, _Subtract, _LessThanOrEqual, _NotEqual), or long (_LessThanOrEqualTo, _NotEqualTo)? I've currently picked the medium ones
2. Do we want to use math operator names like _Multiply / _Modulo, or do we want to use more use-case-agnostic ones like _Times (and what should % be in that case?)

I suggest matching parse.y/Prism token names.

[sampersand]

@ParadoxV5 —while we could, I was thinking we could take this opportunity to be more user-friendly. parse.y uses shorthands like GEQ (link) which people outside of parser development might not understand