Refine error messages with actionable guidance

[doombeaker]

This PR improves error messages across the codebase to help users diagnose and fix common issues without consulting external documentation.

Changes

• Module loading errors (asyparser.cc, dec.cc): Added search path listing and guidance on setting ASYMPTOTE_DIR or creating config.asy.
• Lexer errors (camp.l): Enhanced error messages for invalid integers, real numbers, tokens, and EOF conditions with specific remediation hints.
• File I/O errors (fileio.cc, pipestream.cc): Added suggestions for permission issues, binary mode restrictions, and pipe failures.
• Graphics/Path errors (path.cc, path3.cc, psfile.cc): Clarified requirements for path operations and tensor patch shading.
• External tool errors (util.cc): Added OS-specific installation instructions for LaTeX, Ghostscript, and viewers when executables are missing.
• Rendering errors (glrender.cc, rendererloader.cc): Provided guidance for missing shaders, GLFW window creation, and GLEW initialization failures.

Motivation

Many Asymptote error messages previously stated what went wrong without explaining why or how to fix it. This is especially problematic for new users setting up their environment or encountering missing dependencies. These changes aim to reduce friction and support requests.

All messages are additive (no functional changes) and follow the existing em << / reportError() patterns.

[charlesstaats]

As I understand it, Andy Hammerlindl made a deliberate choice to make error messages purely descriptive, because he has had too much bad experience with software errors giving well-intended guidance that was irrelevant to the actual root cause (because the issue at hand was something the developers had not foreseen). When I was writing the error messages for the templated import system, he had me change some of the error messages I wrote that he considered too guidance-heavy; in his view, I had made assumptions that might not prove to be correct for actual users.

None of this is to say that your changes will necessarily be rejected; it's possible that Andy would look at your changes and decide your hints avoid the issues he is worried about. But it's a reason to be pessimistic. I would avoid investing more time into this sort of change until and unless we can get feedback from Andy.

[doombeaker]

Thanks for the context, @charlesstaats.

It's genuinely helpful to understand Andy's philosophy here. My motivation here came from experimenting with an LLM agent writing Asymptote code: descriptive errors leave the agent guessing, so this was an attempt to be more actionable in that setting.

I'll hold off until we hear from Andy — happy to revise if he's open to it, and completely fine if this direction doesn't end up fitting the project.