Add mechanism to customize agent deployed by kubernetes test runner

`elastic-package` includes a template file with a kubernetes manifest that is used for system tests of some integrations. There are [some concerns](https://github.com/elastic/elastic-package/pull/844#pullrequestreview-998118017) about keeping this file on sync with the reference manifest in the beats/elastic-agent repositories.

A previous approach was to directly download the file from the beats repository on runtime, and patch it in elastic-package, but this is problematic because it doesn't allow to have reproducible builds, or to introduce controlled changes in elastic-package. This can effectively lead to unexpected failures in CI in elastic-package or in any repository with a package that uses the kubernetes service runner.

In https://github.com/elastic/elastic-package/pull/786 we introduced a way to deploy custom agents (using docker compose), and it includes [a mechanism to override settings](https://github.com/elastic/elastic-package/blob/810353f59deb7c88ff8a241663b5671d9d4f1f40/docs/howto/system_testing.md#agent-service-deployer). We might introduce a similar way to override settings in the agent started by the kubernetes deployer.

Some things to take into account:
* Manifests in beats repository are used as reference manifests, manifest in elastic-package is used for testing, they may differ, because the needings are different. We may always need compromises if we use the same files in both places.
* The kubernetes test runner is basically used now only by the kubernetes integration, but it is generic and could be actually used by any integration, we shouldn't guide development only by an specific integration. The kubernetes runner can be a better tool to deploy complex scenarios than the compose one.
* Each integration package can already add additional manifests, current limitation is now only in customizing the agent itself.