docs: document how-to use `terragrunt` with `minikube`, `kubernetes`, and `helm` providers

[caerulescens]

terragrunt is an open source tool created by GruntWorks.io, and it's used as a wrapper to terraform where it provides features that terraform cannot provide. The goal of the documentation is to show another way to use the minikube, kubernetes, and helm providers together because it doesn't replace terraform usage; it extends terraform usage.

This is something that I would like to document for the open source community as I'm not really sure if anyone knows this is possible because I figured it out on my own using terraform-provider-minikube.

There are a lot of advantages:

• terragrunt has dedicated support for opentofu, which fits with @scott-the-programmer and GruntWorks.io's goals to bridge the industry licensing issue that's causing the migration (see #120)
• The terraform project is downloaded using git, which encourages caching and reproducible init / plan / apply sequences through GitOps
• You can use a common configuration for all terraform-provider-minikube usage, which keeps your HCL 100% dry while providing 100% control over common settings between different drivers (docker, kvm2, qemu2, ...). This has a lot to do with how the project's structure is designed, which I would like to cover.
• You can template the values within providers block, meaning that kubernetes_version from terraform-provider-minikube can be templated:

locals {
  kubernetes_version = "v1.28.3"
}

generate "provider" {
  path      = "provider.tf"
  if_exists = "overwrite"
  contents  = <<EOF
provider "minikube" {
  kubernetes_version = "${local.kubernetes_version}"
}
EOF
}

• You can template the values with the remote_state block in a similar way:

remote_state {
  backend = "local"
  generate = {
    path      = "backend.tf"
    if_exists = "overwrite"
  }
  config = {
    path = "${get_parent_terragrunt_dir()}/${path_relative_to_include()}/terraform.tfstate"
  }
}