Function overloading with decorators

[acl-cqc]

@typing.overload allows to describe a number of variants of the same function with different type signatures - but the same actual function body.

We could add @guppy.overload which allows a number of variants of a function with different type signatures, and different function bodies.

For example, consider the range function which has three variants (taking 1, 2 or 3 ints - note, these are not easily satisfied by "default arguments" as the one-argument version provides a value only for the second parameter, with the first parameter defaulting), this could be expressed as follows:

@guppy.overload(builtins)
def range(stop: int) -> Range:
   return Range(0, stop, 1)   # or range(0, stop)

@guppy.overload(builtins)
def range(start: int, stop: int) -> Range:
   return Range(start, stop, 1)

@guppy.overload(builtins)
def range(start: int, stop: int, step: int) -> Range:
   if step == 0:
      raise/panic/etc.
   return Range(start, stop, step)

Each call would be statically resolved by static argument type. We shouldn't need to worry about overlap between cases because guppy has no classes/subtyping (so we should probably require all variants to have identical return type, too - at least until we implement Union).

Hence, this provides a different way to handle functions which would otherwise need Union arguments (at the cost of providing separate code for each).

We could also then extend the frontend (only) to provide python-like default arguments backing onto this, i.e. without any further backend changes, although default arguments probably merits a discussion of its own (e.g. perhaps we require the values to be immutable, ruling out one of the top/worst python "gotchas")...

However, it might prove too much of a stopgap measure, i.e. it seems of limited use when we do have Union compiling to Hugr Sum type.

[ss2165]

Now done! #995