Make the formatting of a code block name extendable

[jasongrout]

Currently the user display of a code block requires a tight coupling between the caching compiler and the ultratb file, i.e., ultratb needs to know internal private variables of the caching compiler. This change makes the user-visible display of the code block name the responsibility of the caching compiler, separating the API more cleanly. A nice result is that the caching compiler can be overridden to have custom terminology in different systems for code blocks executed (for example, in Databricks the "cells" are currently known as "commands".)

I tried to strike a nice balance here between maintaining the existing format exactly and the API of the new method. I think it is a bit weird that the line number formatting is different for files vs cached code blocks (X, line Y vs X:Y). Do we need to preserve the X:Y formatting for automated tools that expect exactly that form for file line numbers?

[jasongrout-db]

I tried to strike a nice balance here between maintaining the existing format exactly and the API of the new method. I think it is a bit weird that the line number formatting is different for files vs cached code blocks (X, line Y vs X:Y). Do we need to preserve the X:Y formatting for automated tools that expect exactly that form for file line numbers?

There is an extensive discussion of this in #13560, and the answer is "yes", and the format difference here is intentional.

[Carreau]

Let's try and see if we get complaints.

[jasongrout]

Let's try and see if we get complaints.

Note that this PR has no change visible to the user - I kept the existing formatting, and just made it extendable.

[jdtsmith]

Some tools parse the UltraTB formatting (at least one flavor of it), so it would be very helpful if iPython sticks to the current format. Hopefully it is expressive enough for Exception Groups too (haven't seen those in the wild).