Generate overloads in be-cs and be-java

[tjpalmer]

#314 adds overloads to Temper, but we should also generate overloads in backends that support it, like C# and Java.

Probably some TmpL option could help.

Should we produce only the overloads or also the unique names?

[mikesamuel]

There's a hazard in Java. Overloads need to have the same post-erasure signature.

For example:

class C {
  // These overloads are ok.
  // They have distinct signatures (Ljava/lang/String;)V and (i)V
  public void fooOne(String s) { ... }
  public void fooOne(int i) { fooOne("" + i); }

  // These are not.
  // They both have the signature (Ljava/util/List;)V
  public static void fooEach(List<String> ls) { for (String s : ls) { fooOne(s); } }
  public static void fooEach(List<Integer> ls) { for (int i : ls) { fooOne(i); } }
}

We might need to store information about which Temper methods were included as overloads so that if one is added that conflicts with another, we know which are in the group for backwards compatibility.

---

Once we've got temper.keep reliable enough, we could also generate overloads in dynlangs.

For example, for the fooOne overloads we could do the following:

// From Temper like
@overload("fooOne")
let fooOneString(s: String): Void { ... }
@overload("fooOne")
let fooOneInt32(i: Int32): Void { ... }

// generate a fooOne in JavaScript
/** @param {number | string} x */
function fooOne(x) {
  if (typeof x === 'string') {
    fooOneString(x);
  } else if (typeof x === 'number') {
    fooOneInt32(x);
  } else {
    panic();
  }
}

Recording which have historically been bundled together in temper.keep would help us avoid problems if an overload was added for fooOneFloat64 which is not distinguishable via typeof.