WIP feat: statically analyze python code to find task plugin function signatures

[chisholm]

Addresses #413

Some caveats:

• Depending on how one normalizes annotations, one can derive the same type name from distinct annotations. That means task plugins with different typed arguments can wind up with the same suggested type names. For example, my current normalization coalesces contiguous underscores to a single underscore and strips leading/trailing underscores, but it is easy to create examples where that is a problem. But without that, you can wind up with suggested types like _list__str__, list_str_, etc. Funny looking type names.
• The signature structure's "outputs" property maps to a list. That suggests support for functions returning multiple values (which does align with how task definitions are). But whether a function returns more than one value is really only in the developer's mind. A given function can be used as if it returned one or more than one value. It's more of a usage difference. If we choose some criteria to distinguish, it will be a guess, and may be wrong. E.g. maybe a return type annotation as "tuple" or "typing.Tuple". Should we guess? If so, what should be the criteria? Currently, signatures only include one output.
• When processing import statements, relative imports are ignored. When all you have is some python source, you don't know what the imports are relative to, so you can't make sense of them.