Easier KRM functions configuration

### Eschewed features - [x] This issue is not requesting templating, unstuctured edits, build-time side-effects from args or env vars, or any other eschewed feature. ### What would you like to have added? Currently configuring a KRM function plugin like a transformer or a generator is done inside the `metadata.annotations` field of the function configuration, where one has to write YAML inside of a string to configure things like networking, the KRM container image, etc. This feels a bit hacky, you can't get autocompletion on what are the configurable fields (I had to dig through the code to find out), and autoformatters don't format it. I think it would be cleaner if the function configuration could be done directly inside the `kustomization.yaml` file. We could add a : `kustomization.yaml` ```yaml functions: - type: "transformer" path: my-krm-function-config.yaml spec: container: image: my/amazing/container:latest network: true ``` ### Why is this needed? Ease of configuration, remove the need to write yaml inside a string ### Can you accomplish the motivating task without this feature, and if so, how? Today, the only way in which one si allowed to configured a KRM function is within the function configuration metadata field. ```yaml apiVersion: myapiversion.dev/v1alpha1 kind: MyKRMFunction metadata: name: example annotations: config.kubernetes.io/local-config: "true" config.kubernetes.io/function: | container: image: my/amazing/container:latest network: true spec: # ... ``` ### What other solutions have you considered? Another option would be changing the `generators` and `transformers` fields to allow setting the same. But that would require a breaking change to what those fields accepts. ### Anything else we should know? Here's a working example of a potential way to implement this feature with minimal code changes required: https://github.com/lorenzofelletti/kustomize/pull/1 ### Feature ownership - [x] I am interested in contributing this feature myself! 🎉