Make custom value type handling more consistent (#12230)

[Context on
Discord](https://discord.com/channels/601130461678272522/855947301380947968/1219425984990806207)

# Description

- Rename `CustomValue::value_string()` to `type_name()` to reflect its
usage better.
- Change print behavior to always call `to_base_value()` first, to give
the custom value better control over the output.
- Change `describe --detailed` to show the type name as the subtype,
rather than trying to describe the base value.
- Change custom `Type` to use `type_name()` rather than `typetag_name()`
to make things like `PluginCustomValue` more transparent

One question: should `describe --detailed` still include a description
of the base value somewhere? I'm torn on it, it seems possibly useful
for some things (maybe sqlite databases?), but having `describe -d` not
include the custom type name anywhere felt weird. Another option would
be to add another method to `CustomValue` for info to be displayed in
`describe`, so that it can be more type-specific?

# User-Facing Changes
Everything above has implications for printing and `describe` on custom
values

# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`

crates/nu-command/src/debug/explain.rs

@@ -294,6 +294,11 @@ pub fn debug_string_without_formatting(value: &Value) -> String {
         Value::Error { error, .. } => format!("{error:?}"),
         Value::Binary { val, .. } => format!("{val:?}"),
         Value::CellPath { val, .. } => val.to_string(),
-        Value::CustomValue { val, .. } => val.value_string(),
+        // If we fail to collapse the custom value, just print <{type_name}> - failure is not
+        // that critical here
+        Value::CustomValue { val, .. } => val
+            .to_base_value(value.span())
+            .map(|val| debug_string_without_formatting(&val))
+            .unwrap_or_else(|_| format!("<{}>", val.type_name())),
     }
 }