[#906] Better errors on stuck GetEntrypointArgCustom

No bright ideas on how to test this. Tried using deferred type errors, but those apparently don't capture custom TypeErrors.

One curious side effect is that in some cases, constraint arg ~ GetEntrypointArgCustom cp mname would have to be replaced with HasEntrypointArg cp (EntrypointRef mname) arg. AFAICT, this is an equivalent transformation: this would be required only when polymorphic code actually wants HasEntrypointArg constraint, but it was provided by providing the instance constraints instead.

Description

Problem: HasEntrypointArg has an equality constraint on GetEntrypointArgCustom in one of its instances. The latter can get stuck in polymorphic code, which produces pretty unreadable error messages due to using first-class-families under the hood. This might be fine when GetEntrypointArgCustom is used directly, but when FCFs leak into high-level user code using HasEntrypointArg, perhaps indirectly, it's not ideal. The motivating example is transfer from Cleveland.

Solution: Detect when GetEntrypointArgCustom gets stuck in HasEntrypointArg constraints and print a more user-friendly error message, suggesting adding the appropriate constraint explicitly.

Related issue(s)

Resolves #906 (closed)

✅ Checklist for your Merge Request

Related changes (conditional)

• Tests (see short guidelines)

  • If I added new functionality, I added tests covering it.
  • If I fixed a bug, I added a regression test to prevent the bug from silently reappearing again.

• Documentation

  • I checked whether I should update the docs and did so if necessary:
    • Root README and other README.md files
    • Haddock
    • docs/
  • I updated changelog files of all affected packages released to Hackage if my changes are externally visible.

Stylistic guide (mandatory)

• My commits comply with the following policy.
• My code complies with the style guide.