bug#51037: [PATCH] Make `print-level` & `print-length` customizable in ERT batch tests

[Gemini Lasswell <gazally@runbox.com>]

Michael writes:

> My personal incliniation is to remove the `backtrace-line-length`
> variable entirely, and make the `debug` package responsible for
> controlling print-level so as to avoid 31919. But that's me: is
> there a compelling use-case for backtrace.el working in terms of
> limiting line length rather than just using `print-le{ve,ength}`?

The motivation for `backtrace-line-length` was to find a compromise that
made backtraces more user-friendly in interactive debugging for both
small and large data structures.  Setting `print-level` and
`print-length` too small will create a lot of ellipses in small data
structures, making you have to expand those ellipses to see your data;
setting those variables a little bit bigger will unleash exponential
growth in line length for large data structures, causing delays of
seconds to minutes when rendering and navigating your backtrace.  The
heuristics in `cl-print-to-string-with-limit` try to do a reasonable job
with both small and large data structures, so the user can get on with
debugging, rather than first having to figure out values of the `print-`
variables which will make debugging possible.

Another goal of backtrace buffers is to make the data structures
represented there be completely navigable, which is why lines are not
simply truncated.

If you don't want ellipses in your backtraces, then bind
`backtrace-line-length` to nil or zero.  If you want to see how long a
backtrace line can get, try that out with magit or org-export.