util: canonicalize namespaced tags in inspect()

[Renegade334]

Precursor to adding support for Temporal objects in #63154.

Namespaced toString tags are becoming more common in ES builtins. inspect() currently has no logic for dealing with these, leading to rather ugly output:

> new WebAssembly.Memory({ initial: 1 })
Memory [WebAssembly.Memory] {}

This PR adds logic to handle namespaced tags. If the basename of the namespaced tag matches the constructor name, then it will be treated as the canonical name for that object. Derived classes retain the same behaviour as exists currently.

> class Class {
>   get [Symbol.toStringTag]() { return 'Namespaced.Class' }
> }
> new Class()
Namespaced.Class {}

> class DerivedClass extends Class {}
> new DerivedClass()
DerivedClass [Namespaced.Class] {}

Note that this replaces, and effectively reverts, some previous logic that existed here from #59687. That PR made partial string tag matches be considered hits, so FooBarBaz would match Foo and suppress the additional tag output. This logic doesn't really fit with namespaced tags, and I think the easiest approach is just to replace it entirely. (cc @BridgeAR, @miguelmarcondesf)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.04%. Comparing base (a2aeb72) to head (b7bebca).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #63257   +/-   ##
=======================================
  Coverage   90.03%   90.04%           
=======================================
  Files         713      713           
  Lines      224950   224945    -5     
  Branches    42531    42530    -1     
=======================================
+ Hits       202527   202541   +14     
+ Misses      14218    14187   -31     
- Partials     8205     8217   +12     

Files with missing lines	Coverage Δ
lib/internal/util/inspect.js	99.54% <100.00%> (+0.03%)	⬆️

... and 28 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[legendecas]

I think it is not straightforward to write a class with . in its name, like class Namespace.Class {} is not valid. So we can branch here with the presence of . and keep the original behavior, right?

[Renegade334]

As in the previous suppression behaviour?

I really do think that divergent behaviour isn't helpful here – there's no difference between the inheritance models of class MapDerived extends Map and class InstantDerived extends Temporal.Instant, so I can't see that formatting one as a primary class and one as a derived class is at all useful for users.