Rethink overloading

As Julia demonstrates, ad hoc overloading is a great fit for numerical computing! In Dex we have some support for it, in the form of interfaces (type classes), but I would claim that it's still a little less ad'hoc then we would like (in the spirit opposite to How to make ad-hoc polymorphism less ad hoc that introduced type classes). In particular, when defining a type class one has to pick a single type signature that would then be enforced on every single implementation. The big benefit of this approach is that it plays very well with parametric polymorphism and type inference, but it does limit expressivity. For example, when defining interface Mul a it is tempting to just say

(*) : a -> a -> a

but that means that no one will ever be able to overload * to represent the common Python idiom of "a" * 4.

I'm not sure what the options are, but we should do something about it. Julia's standard library features over 20 types for matrices and it would be a shame to miss out on this. One potential solution would be to add support for type-directed name resolution (which is already supported in Idris). It doesn't play quite as well with polymorphic functions, but it does work well in monomorphic environments like at the top level.

(cc @oxinabox for any insights)

No source files, tests, or entry points are named. Start by reading the issue's discussion of Dex interfaces, Julia's overloading model, and the linked material on type-directed name resolution. Done would require an agreed approach for more expressive overloading, but the issue does not define a concrete implementation scope or acceptance test.