Refactors topdown service to support multiple types of calculations and adds support for Sapphire Rapids

[ilumsden]

This PR refactors the topdown service to allow it to be easily extended to support top-down calculations for processors besides Haswell/Broadwell. To do this, I've made the following changes:

• Creates a new TopdownCalculator base class to represent calculations for different processors
• Moves the existing calculations to a new HaswellTopdown class, which inherits from TopdownCalculator
• Refactors IntelTopdown to offload all the computation and associated tracking to a pointer to a TopdownCalculator object

This PR also uses this new infrastructure to add support for Sapphire Rapids and Emerald Rapids CPUs. The calculations for these CPUs were obtained from Intel's perfmon repo, specifically the following file: https://github.com/intel/perfmon/blob/main/SPR/metrics/perf/sapphirerapids_metrics_perf.json. The support added by this PR only covers the first two levels of the top-down hierarchy. In the future, this could be expanded to cover as much of the 6 levels for Sapphire Rapids as desired.

This PR is still work-in-progress. The following tasks need to be completed before this is ready for review:

• Add a CMake mechanism to specify an architecture (currently planning on supporting architecture names from archspec)
• Use that mechanism to select (at build time) the correct TopdownCalculator child class to use in the topdown service
• Examine if any changes need to be made to the topdown built-in option

[ilumsden]

In the future, it might be useful to consider embedding archspec-json if more architecture-specific features are added to Caliper.

[ilumsden]

Outstanding work on this PR:

• Find a way to use PAPI multiplexing with the SPR counters needed for topdown Deferring as future work since it is not needed at this time
• Add testing
• Update documentation (if it exists) about the topdown service

[ilumsden]

This PR is fully tested on Poodle and is now ready for review. There are only a few outstanding things left, namely adding documentation.

[daboehme]

Hi @ilumsden, there's a new change in Caliper this week that breaks up the giant option spec string in controllers.cpp. That was mainly because we ran into MSVC's string literal size limit, but it also makes it so we can pick options based on the build configuration. I think that's a better approach for selecting the topdown options than adding a new ConfigManager function. Can you try and adapt the PR to the new approach? Essentially you can define separate option spec strings for each configuration in controllers.cpp and then add whichever one is appropriate to the builtin_option_specs_list in ConfigManager.cpp. Should be pretty self-explanatory. Thanks!

[ilumsden]

@daboehme I've worked that change into the PR. I did have to make one small change to that mechanism to handle architecture detection. I had to move where builtin_option_specs_list gets populated from global scope to the constructor of ConfigManagerImpl due to having to do string comparison (which is extremely difficult to do at compile time in C++11).