[Feat] Debug improvements

[wingertge]

• Moves debug info from separate instructions that need to be kept in order, to an optional field on each instruction. The scope keeps track of the current debug location if debug symbols are enabled, and attaches that location to each instruction.
• The scope also keeps track of the unique set of kernel function sources so consumers don't need to scan over all instructions to find any NonSemantic::Sources and correlate them to specific functions.
• Adds #line directives to C++ so we have at least some debug info. Example:

#line 108 "crates/cubecl-linalg/src/matmul/components/batch/one_to_one.rs"
  const uint l_3 = l_2 - uint(1);
  const uint l_4 = info[info[uint(9)] + l_3];
  const uint l_13 = info[uint(8)];
#line 22 "crates/cubecl-linalg/src/matmul/components/batch/shared.rs"
  const uint l_14 = l_13 - uint(2);
  const uint l_15 = info[info[uint(11)] + l_14];
#line 22 "crates/cubecl-linalg/src/matmul/components/batch/shared.rs"
  const uint l_16 = blockIdx.z * l_15;

• Variables that represent actual bindings in Rust now have their names tracked so they can be properly labeled in the debug info.

Finally, the actual Rust source can now be attached in one of two ways:

1. Setting the src_file argument on at least one #[cube] macro per file. This uses the fact that include_str! is relative by just including a file in itself. But to do that we need to know the actual name of the file.
2. Using a nightly compiler and setting the CUBECL_DEBUG_NIGHTLY environment variable during compilation. This will use the unstable Span::source_file API to automatically fetch the source and include it in the source_expand invocation.

[nathanielsimard]

I would also add an example output in the PR!

[nathanielsimard]

I'm curious what it looks like!

[wingertge]

I added an example to the PR text. A debugger/profiler should use these to keep track of actual source locations, but I don't know how well they actually keep track of things especially with the JIT compiler.

[nathanielsimard]

What's the difference between the two?

[wingertge]

The entry_loc is basically just the first source_loc ever set for a kernel, so we can set the source loc at the start of a kernel without having to look ahead to the first update. Otherwise you'd need to always scan ahead which is harder than just keeping track of the first value.