Bug: inferred func names are ambiguous, cause misbehavior due to alias

[Groxx]

See #537 for a pull-request with an example of the misbehavior.

---

RegisterActivityWithOptions registers an inferred func name into a map containing {inferred-name: registered-name}, I assume to allow you to execute activities with either their registered-name or their function, for simplicity.

Unfortunately this is unsafe - reflected function names are not guaranteed to be unique. And it's relatively easy to encounter if you generate workflow or activity functions (as can easily occur in tests, and could occur IRL as well, though generally you'd just pass those args to a shared activity).

TBH I'm not fond of allowing ambiguous calls like this enables, but that's mostly irrelevant. This silently produces incorrect behavior, which it should not do.

Making it error on duplicate-inferred-names would prevent a silent failure... but it'd also mean you cannot generate activities / workflows at all.
And trying to allow generated activities / workflows while also allowing ambiguous calls doesn't seem easily possible... func addresses would work for anonymous funcs, but for named ones you can only get the address of the var, not the "canonical" one. Maybe something with reflection -> function pointer address?