chapel-py: expose Dyno error data in Python API, improve error messages.

[DanilaFe]

This all started because the language server was not giving me detailed enough information about why calls are not resolving.

Why are there no matching candidates?!

I think there might be some kind of method or setting in my editor to show detailed information (which would include the failing candidates). However, if only a particular argument is causing the problem (as it is in the case above), why not highlight that specific argument?

This was not possible in chapel-py's previous state of things. It exposed the parent Error class to Python, which included .message() and the additional notes. However, these notes are in plain English, and make it hard to work backwards to find the (e.g.) actual that caused the issue. However, from the get-go (as described in #20701), our errors were designed to separate the content of the error from its presentation. To this end, different error sub-classes contain bundles (tuples) of information, from which we can determine the erroneous actual.

The goal of this PR, then, was to plumb this wealth of additional information into chapel-py proper. I did this by:

• Using the established "generated types" approach to create a Python class corresponding to each error message type. This approach was previously applied to AST nodes, types, and params. I modify generated-types-list.h to adapt all the error messages we have listed in error-classes-list.h. Notably GeneralError is not a generated type in plain Dyno, but I treat it as such in chapel-py for uniformity. This required a tiny bit of boilerplate on Dyno's front, adding ->toBlaError() methods to ErrorBase.
• To expose each individual error's info bundles, I needed to provide a Python info method for each error message. The type of this info method differs for every error message, but more importantly, not all information exposed by error messages can be converted into Python data. To make progress, and to guard against future error messages adding new, unsupported error information, I wrote some template code to produce 'Python-safe' tuples from arbitrary ->info data.
  • These tuples replace unsupported types (ones that aren't explicitly "blessed" as Python-compatible) with zero-element tuples. There might be other options (std::monostate?), but we already have support for tuples, so using them was the path of least resistance.
  • Unlike "regular" methods (as in uast-methods.h), which can be precise about whether their return type can be nullptr or not via the Nilable wrapper, the error-classes-list.h macro header does not provide such information. Thus, we must assume any pointer type contained in the ->info() can be nullptr. This requires a recursive transformation that tags pointer types as such, implemented by CanConvert::transform.
  • Finally, I used the error-classes-list.h header to generate each unique ->info() methods within the method table. All this was big and complicated enough that I broke out a separate error-methods.h header.

The net result is a Python class hierarchy with info methods that produce tuples of the data we required.

To make my specific improvement, I then exposed ApplicabilityResult, a list of which is included in the NoMatchingCandidates error. This ApplicabilityResult includes the actual of the call that could not be passed. This conversion is nigh-trivial, since our PythonClassWithContext abstraction provides working defaults with nearly no additional boilerplate.

With this, I was finally able to write my logic in chapel.lsp to provide more specific locations for errors in which a single actual caused all candidate matching failures. I also went ahead and provided nicer error locations for a few other error messages.

Before	After

My future work for this is to explore using the newly-provided error information for other things, such as fixits for simple errors. This PR is complicated enough now that I do not intend to do that here.

Reviewed by @jabraham17 -- thanks!

Testing

• dyno tests
• CLS tests

[jabraham17]

I won't pretend to full understand this code. But I see no obvious errors

[jabraham17]

nit, use tuple unpacking like the other statements

[jabraham17]

It took me way too long to grok that appress -> ApplicabilityResult. Consider app_results and app_result