Energy profiling tools: Core infrastructure with timing tool and export capabilities

[ethan-puyaubreau]

This PR introduces the foundational infrastructure for energy profiling tools in Kokkos:

Features:

• Timing Infrastructure: Timing system with TimingInfo structure and region tracking
• State Management: Thread-safe EnergyProfilerState singleton for managing active/completed timing regions
• Region Types: Support for ParallelFor, ParallelReduce, ParallelScan, DeepCopy, and UserRegion profiling
• CSV Export: timing_export module for exporting timing data to CSV files with summary statistics

Implementation:

• Main Library: kp_energy_profiler - Core profiling functionality
• Utilities: timing_utils.hpp/cpp - State management and helper functions
• Export: timing_export.hpp/cpp - CSV export and summary generation
• No External Dependencies: Self-contained implementation using only standard C++ libraries

Architecture:
This infrastructure provides a clean separation between timing collection, state management, and data export, making it easy for future energy monitoring providers to integrate their functionality. The design supports both synchronous and asynchronous profiling patterns (if combined with #300).

[JBludau]

first pass

[ethan-puyaubreau]

@dalg24 @masterleinad Hello! I would need some review on this PR, being the baseline blocks needed the daemon system and energy measurement tools (that would also need review #300)

[JBludau]

I think we are getting there

[dalg24]

Fine but noting that if you can't correlate start and end of a region via some identifier then it won't be threadsafe.

[dalg24]

This red circle means "no newline at end of file".
Please fix it by adding a newline character.
Same comment everywhere.

[dalg24]

Suggested change

	namespace KokkosTools {
	namespace EnergyProfiler {
	std::string generate_prefix() {
	std::string KokkosTools::EnergyProfiler::generate_prefix() {

[dalg24]

Suggested change

	namespace KokkosTools {
	namespace EnergyProfiler {
	namespace KokkosTools::EnergyProfiler {

[JBludau]

hmm ... afaik that is not how exceptions are supposed to be used ... especially since you are not handling the exception but just printing and not rethrowing. So this would not lead to an abort.

if any of the functions in the try block throw, you are silencing that but also not restoring a valid state so that the program can continue. I would remove the try-catch

[JBludau]

when starting, you should take the time at the end and then use it to update the last region in the dqueue. This way you don't measure the construction or the lock

[JBludau]

As I am writing this: It of course does not hold for nested regions ... but that is too much for now