Allow disabling of function name aliasing during registration

[cretz]

Is your feature request related to a problem? Please describe.

Today when given a name to register workflows (and activities?) with, we also effectively register the function name and we don't check for uniqueness like we do with the explicit name. So when the workflow is called by function reference, it could still suffer ambiguity.

Describe the solution you'd like

Add workflow.RegisterOptions.DisableFunctionNameAlias to disable this default aliasing (and activity too?). We can't make the disable default due to backwards-compatibility reasons.

Describe alternatives you've considered

We could just live with it and tell people that are registering with a string name that they have to call by string name too or we won't protect them. But this is a trivial change.

[laniehei]

maybe related? 🙃 #425

[cretz]

After discussion, the better handling of this issue is to qualify the alias. Will probably close this and do that when this issue is tackled.

[cretz]

This is also happening during test suites in surprising ways. Take this example:

env.RegisterWorkflowWithOptions(somepkg.MyWorkflow, workflow.RegisterOptions{ Name: "MyCustomName" })
env.ExecuteWorkflow(someotherpkg.MyWorkflow, "foo", "bar")

Even though ExecuteWorkflow attempts implicit register, it silently ignores as expected if already registered. The ExecuteWorkflow actually tries to execute the registered one due to the alias which is very confusing.