[core] Add more debug string types

[dentiny]

Followup on #47893, add more "blessed container types" to debug string function.

Share some of my thoughts (some are irrelevant to this PR):

• The current implementation could be improved
  • There're a few types that we miss, if we want to general-purpose printer: std::byte, enum, types which supports absl stringify, fallback printer (which prints type and address, like python) if non existing printer matches;
  • A good use case for general-purpose printer would be:

    ray/src/ray/util/logging.h

    Lines 151 to 154 in 4ab6b7c

    	#define RAY_CHECK_OP(left, op, right) \
    	if (const auto &_left_ = (left); true) \
    	if (const auto &_right_ = (right); true) \
    	RAY_CHECK((_left_ op _right_)) << " " << _left_ << " vs " << _right_

• We better split bazel targets
  • For example, all files under src/ray/util are contained in one single giant target, which greatly increase the compilation, link and test time

[dentiny]

@jjyao / @rynewang Would appreciate a review :)

[rynewang]

do we have any usage of this specialization?

[dentiny]

In this PR, I'm trying to add well-known types to debug string.

[rynewang]

I feel we can use our dev times more conservatively - only add a specialization when we need one. Similarly, we can split the build target but it should not help much since this header file is compiled with callers anyway (so all downstreams are rebuilt). Since this PR is already out we can merge it but for other ideas let's create a PR to track it (as P2) and I will find some other issues for you.

[dentiny]

I feel we can use our dev times more conservatively - only add a specialization when we need one.

The best way is to templatize it, like the example I showed you last time;
If you don't like it, we could use gtest printer as well (https://github.com/google/googletest/blob/main/googletest/include/gtest/gtest-printers.h);
It's not perfect, still missing a few types, but generally usable, and allows customization via PrintTo and ADL.

Since this PR is already out we can merge it

Thank you!

Similarly, we can split the build target but it should not help much since this header file is compiled with callers anyway (so all downstreams are rebuilt).

Yes all downstream targets will be rebuilt, but that's oneshot effect.
Breaking targets into small pieces help compilation and link time.

I also notice we don't use static link for cc_test targets, which slows down tests.

[dentiny]

Similarly, we can split the build target but it should not help much since this header file is compiled with callers anyway

The reason why I care so much about bazel target granularity is every time I try to build GCS job manager and utils targets, it's taking me 20-30 minutes, depending on cache hit rate.