Initial implementation of plugins

[tconley1428]

What was changed

Added ITemporalClientPlugin and ITemporalWorkerPlugin to provide configurability to their respective objects. SimplePlugin was added to make it easier to implement plugins consistently across objects.

Why?

It can be difficult to provide consistent and easy methods of configuring temporal objects.

Checklist

1. Closes [Feature Request] Plugin support #507 #plu

2. How was this tested:
   New set of plugin tests.

3. Any docs updates needed?
   Plugin documentation in general is pending.

[cretz]

All looks good to me, but I'm a bit biased because I was involved in the coding. @maciejdudko - can you take a look at this review?

[jmaeagle99]

Wrote some thoughts down, but feel free to take or leave any of them.

[jmaeagle99]

Why is this nullable? Would it not be sufficient to declare the usage of the SimplyPluginOption<T> as nullable itself? The only scenario I can think of where you might need this is if you want to say that this option doesn't have a non-null default value and you want to have the configurable callback; this feels like a simplified design of the options pattern in .NET where any number of consumers of the library could implement IConfigureOptions<T> and IPostConfigureOptions<T> for declaring and registering callbacks for mutating options before a consume of the options gets the final value.

[tconley1428]

That does sound similar. It's trying to mimic what I did in the other languages with either taking a value or a function that produces it. The options pattern seems to be doing the same thing.

[cretz]

In this side of the SDK, we don't make any assumptions about IConfigureOptions and such, so we can only provide naive forms of callback-based options mutations. So this is effectively a "constant or function" mutually exclusive option value. Technically we could have made a whole abstract base class sum type thing, but this class should be rarely used anyways.