Formatter options for TypeSafeIndex and Identifier

[jwnimmer-tri]

Is your feature request related to a problem? Please describe.

When an error message incorporates a TypeSafeIndex<Tag> (e.g., BodyIndex) or Identifier<Tag> (e.g., GeometryId), right now the default fmt::format output for that value is just the underlying bare integer. The type (e.g., "body" or "geometry") might not always be clear from context, so sometimes the error message text needs to laboriously incorporate the type.

drake/multibody/tree/element_collection.cc

Lines 151 to 153 in 63201f5

	throw std::logic_error(fmt::format(
	"The given {}Index({}) is out of bounds (must be less than {})",
	nice_type, index, next_index()));

Describe the solution you'd like

Enhance TypeSafeIndex<Tag> and Identifier<Tag> to offer a repr formatter, so that the format string could be something like fmt::format("The given {:r} is out of bounds", index).

Describe alternatives you've considered

N/A

Additional context

N/A

[SeanCurtis-TRI]

After seeing #24936, I have a doubt.

The format string {:r} (as mooted above) is currently not a valid format string (that's good). However, it is a substring of something that is valid: {:r>10}. One can't help but wonder that the existence of the former implies the latter. But the latter has a completely different meaning than what we might infer from the existence of {:r} (it is not a right-aligned 10-wide column with the repr(id) placed in it. I'm thinking we might want a format string that neither exists nor would be the substring of an otherwise valid expression.

For the sake of argument, let's say it were {:r:}. If that were the case, we could do {:r:>10} or {:r:x>10} which would produce MyId(1) and xxxMyId(1), respectively. I'm not arguing that we necessarily need to do this, but I do feel strongly about the non-substring-of-valid-format-string thing.

---

@sherm1 had mooted the idea of fmt_repr() as in fmt::format("Found bad id: {}", fmt_repr(id)); It would only have pesudo-repr semantics in that it would wrap the to_string() format in the NiceTypeName() (or some such thing).

Anyways, before pulling the trigger on :r, we should ruminate a bit more.

[jwnimmer-tri]

I support using unambiguous syntax.

The benefit of the built-in format string is that it aligns with how formatting is typically customized, and could be extended with other format patterns in the future. The benefit of the wrapper function is that it's less "magical" syntax for the developer to need to memorize / look up. There's arguments both ways, but I do like the compactness of the former.