Better kernel debug support

[nsmithtt]

• Introduce debug singleton object used to hold debug environment information during runtime. This could be a good place to store new kinds of debug flags in the future for runtime.
• Wire it up through ttrt.
• loadKernelsFromDisk added to denote reloading of generated kernels from /tmp, from previous run, instead of loading them from the flatbuffer.
• Name the kernels with program and location info from the MLIR graph. Now names look like:

                      /tmp/ttmlir_multiply_%5_tensix.cpp
                                  ^        ^  ^
                       Func name -/        |  |
                                           |  |
                         Result Value Loc -/  |
                                              |
         Thread type/info [noc, eth, tensix] -/

• Usage with ttrt:

# Run ttrt per usual
ttrt run simple_eltwise.ttm

# List kernels
ls /tmp/ttmlir_*

# Edit kernel
vim /tmp/ttmlir_multiply_%5_tensix.cpp

# Reload kernels from disk
ttrt run --load-kernels-from-disk simple_eltwise.ttm

[kmabeeTT]

Looks awesome. Was just realizing today that program name wasn't visible to kernels so this is timely and handy.

[pjanevskiTT]

Looks great!

[rpavlovicTT]

@nsmithtt I noticed we dump only 1 kernel per thread type, but we create data movement kernels for every core independently. And maybe we'll have split compute kernels per core groups too. Should we dump all of them?

[nsmithtt]

@nsmithtt I noticed we dump only 1 kernel per thread type, but we create data movement kernels for every core independently. And maybe we'll have split compute kernels per core groups too. Should we dump all of them?

Good point, we should encode the core grid shape / offset in the string name, i.e. one kernel per entry in the core_range_set. If you have time to add this it'd be much appreciated!

[rpavlovicTT]

@nsmithtt I noticed we dump only 1 kernel per thread type, but we create data movement kernels for every core independently. And maybe we'll have split compute kernels per core groups too. Should we dump all of them?

Good point, we should encode the core grid shape / offset in the string name, i.e. one kernel per entry in the core_range_set. If you have time to add this it'd be much appreciated!

Sure, #794 issue tracks it, will fix it at some point.