feat: reimplement storage class with hashicorp/kubernetes provider

[mercuriete]

Fixes #8

Motivation in our internal CICD system the kubectl provider was not working properly and we want to use an official provider for doing that functionality.

It is not a breaking change but It will destroy the storage class and create another one with the same name.
This was tested on my internal EKS cluster and everything worked properly.

Types of changes

What types of changes does your code introduce to <repo_name>?
Put an x in the boxes that apply

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update (if none of the other choices apply)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• I have read the CONTRIBUTING.md doc.
• I have added necessary documentation (if appropriate).
• Any dependent changes have been merged and published in downstream modules.

[Lillecarl]

resource "kubernetes_storage_class" "efs-dp" {
  metadata {
    name = "efs-dp"
  }

  storage_provisioner = "efs.csi.aws.com"
  parameters = {
    provisioningMode = "efs-ap" # Access point
    fileSystemId     = module.efs.id
    directoryPerms   = "700"
    # gidRangeStart: "1000" # optional
    # gidRangeEnd: "2000" # optional
    # basePath: "/dynamic_provisioning" # optional
  }
}

This is how i ended up doing our SC for dynamic provisioning, straight out the controller YAML example.