Better Task Failures when passing incorrect options to Execute[Local]Activity

[Sushisource]

Is your feature request related to a problem? Please describe. If you pass ActivityOptions to ExecuteLocalActivity or make the inverse mistake, right now that'll surface as a task failure generated by server along the lines of you missing one of the required timeouts. This is technically true, but can be a source of confusion to a user looking at their code and saying "I am setting a timeout" without realizing that the real problem was they specified the wrong kind of options.

Describe the solution you'd like We should explicitly fail the task from the SDK side with an error message making it clear that the wrong type of options were applied to the context for the call being made.

[cretz]

The problem here is that you're not "passing" things to these calls, they are just set on the context somewhere before. That one set of options may be present does not mean there was an options mixup. But having said that, yes, if we don't give a clear error message that (local) activity options are not set on the context, we should (and clearly state which ones must be set).