Create caching layer for autotuned configs

[jansel]

Right now the development model is people should copy and paste configs from autotuning output into their code. This is nice and predicable for a single device type, but if one is using many different types of hardware it may not be ideal.

We should create some sort of caching mechanism for autotuning, that allows a team with a collection Helion kernels to autotune all kernels for a new set of hardware easily.

Perhaps we can reuse some of the inductor caching infra for this.

We should have a way to provide example inputs for autotuning.

A key invariant we should maintain is an ahead-of-time autotuning model. Autouning should happen before deployment, not after deployment.

[jansel]

Some more ideas here, maybe something simple would be:

@helion.kernel(autotune_cache="~/.helion_cache.json")
def foo(...):
   ...

1. We should have a configurable cache key. Maybe something like autotune_cache_key="{source_code_hash}-{function_name}-{input_dtypes}-{input_shapes}-{device_name}" to allow people to customize what triggers re-autotuning.
2. We should think about how to extend this to remote caches, since that is something we will need at some point, and we should build it into the design.
3. We should have some way to register kernels for ahead-of-time autotuning. I am thinking of the case where a project has dozens of custom kernels, and then they want to support new hardware. It would be really nice if they could run a single command and re-tune everything.

[oulgen]

will work on this this week, we can start simple similar to how inductor does autotuning best config, and customize from there