[tuner] Generalizes Configuration dataclass

[mihaescuvlad]

Notes:

• Splits Configuration into LLVMGPUConfiguration & LLVMCPUConfiguration
• Adds device_target to the MlirRegex dataclass
• Adds SolutionGenerationStrategy for decoupling the solution generation from the configuration
• Adds SolutionStrategyFactory to fetch the proper solution strategy based on target architecture
• Adds Mmt4d pipeline support

Tests:

• Architecture tests:
  • Adds separate tests for GPU and CPU solution & constraints generation
• Tuning tests:
  • Adds separate tests for GPU and CPU tuning
  • Adds tests for Mmt4dTuner

Improved Usage:

• Automatic Architecture Selection: The target architecture is automatically detected from the input.mlir file. The correct configuration and solution strategy are chosen accordingly, with no user input required, apart from compiling the input.mlir for the intended architecture in advance

[kuhar]

I think the key consideration should be how to generate the constraints. I think this should belong to each configuration: given a problem size and dispatch kind, it should know how to generate constraints and perform the lookup in the model generated by Z3 to apply the assignment

[kuhar]

Why do we need these builders?

[mihaescuvlad]

That was one of the only ways of creating the configurations that I could think of while trying to avoid hacks. I tried using a strategy pattern before, but it was slightly less clear than using builders + factory. It's still not a perfect approach though, because the generate_solutions method still loses some of the clarity. I'm considering moving that method inside of the configuration dataclasses and getting rid of the builder while keeping a factory for creating the configurations