Generate doc summaries with references to Python function

[atifaziz]

As an interim measure to #260 and also when any doc string is missing, this PR proposes to add the python function's signature to the summary of C# proxy method. In IDEs, this has the benefit of immediately being able to examine the C# & Python signatures during auto-completion or by just hovering over and without needing visibility and debugging support of the generated code:

The source lines of the function are capture into PythonFunctionDefinition during parsing and emitted into method summaries during code generation.

Each interface generated for a module's function also has a summary that calls out the Python module name:

The effects of the changes can be examined in the snapshots of the generated code that have been updated in this PR in order to pass the tests.

[tonybaloney]

What happens if:

1. The function is defined over multiple lines
2. The function contains a comment that has an escape, albeit unlikely e.g.

def foo(): # /// </summary

[atifaziz]

What happens if:

1. The function is defined over multiple lines

It will get carried over into the comment as-is, e.g.:

public interface ITestClass : IReloadableModuleImport
{
    /// <summary>
    /// Invokes the Python function <c>test_int_float</c>:
    /// <code><![CDATA[
    /// def test_int_float(
    ///         a: int,     # first arg
    ///         b: float    # second arg
    ///     ) -> float:     # return type
    /// ]]></code>
    /// </summary>
    double TestIntFloat(long a, double b);

Are you seeing an issue I'm not?

2. The function contains a comment that has an escape, albeit unlikely e.g.

def foo(): # /// </summary

Technically this will be fine because the Python code is wrapped in a CDATA section so /// </summary> won't get parsed as XML, but yeah, if someone is bent on breaking things, they can close the section with # /// ]]></summary. This will cause a CS1570 warning (if documentation file generation is requested), but not an error unless all warnings are being treated as errors. Then again, you'll also get lots of CS1591 warnings about missing XML comments on public members that'll need addressing (which is a separate topic to tackle) before you can get round to CS1570 ones.

Would you rather have the comments removed entirely? Another option would be to format back the Python signature from the parsed PythonFunctionDefinition rather than the original source code lines, which would get rid of trivia such as comments and line wraps and also provide consistent formatting.