Remove abstract_command::debug_label

[fknorr]

Currently, the DOT graph generation for print_graph happens partially in graph_generator, which stringifies the data requirements into the abstract_command::debug_label. In addition to the missing separation of concerns, this is surprisingly slow as it uses iostreams to print the GridRegion of each requirement.

This PR moves this entire printing logic to print_graph.cc and removes the debug_label member. It also simplifies the remaining printing code by replacing iostreams uses with fmt.

The CI failure on dpcpp:HEAD is due to a bug in Clang 15 and not related to this PR.

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[PeterTh]

Given that there are formatting changes but no changes to any test, I assume we don't have any. Maybe it would be good to add at least a simple basic graph printing unit test (ideally in a commit before the change).

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[fknorr]

I have used the opportunity to improve readability and information density of the graphs overall:

Also, there are now smoke tests checking that task and command graphs remains unchanged for two example programs.

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[psalz]

This is great! The graphs look much nicer now.

In addition to the missing separation of concerns, this is surprisingly slow as it uses iostreams to print the GridRegion of each requirement.

Have you tried running the microbenchmarks to see whether this is measurable?

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[fknorr]

Here's a comparison for CDAG generation benchmarks between master and this branch:

This suggests a significant overall performance improvement, especially in the 4-node case - although it is curious why the same difference can't be seen for the 16-node case.

[PeterTh]

LGTM. Re:16 threads - my guess would be that the improvement from getting rid of this string processing only scales linearly with the number of nodes, while many other overheads scale non-linearly, so the relative impact is reduced at increasing node counts.