Feature/inject init containers

[iwilltry42]

What and why?

Note: this PR assumes that the hostAliases PR got merged already (too lazy for some more merges).

Note 2: I "simplified" adding tests in internal/pkg/config/config_test.go similar to how it's done in loader_test.go.

Functionality to add initContainers, because they're quite useful sometimes and some functionality, that we currently execute in sidecar containers may only be needed once at the start of a pod.

This works similar to the injection of "normal" containers, meaning that, if there's a name conflict between injection config and the requesting podSpec, the server will return a Duplicate Value error.

Testing Steps

Tested with debug-pod that requests an injection with one initContainer in it.
Configs of debug-pod tested:

• 0 existing initContainers
• 1 existing initContainer
• 1 existing initContainer with name conflict

Same unittests as usual.

Reviewers

Required reviewers: @byxorna
Request reviews from other people you want to review this PR in the "Reviewers" section on the right.

[byxorna]

This looks great @iwilltry42 ! @zach-dunton-sf just opened up #9 to do the same, and there are useful features (fixes to annotation escaping in patches, and unit test refactors) in both PRs that I feel should be merged. Mind coordinating to negotiate which gets merged in?

[iwilltry42]

@zach-dunton-sf can I merge your changes regarding annotations into this PR? That way we can have all the functionality without having to mess with merge conflicts. And as far as I can see, our changes regarding the injection of initContainers are fairly similar.

[iwilltry42]

@byxorna I pasted @zach-dunton-sf 's changes regarding annotations into my branch 👍

[byxorna]

Awesome 👍
cc @komapa @defect for final eyes?

Closes #7 and #9

[byxorna]

@iwilltry42 ok, thanks for all this! I am merging and will cut a new release in a bit; you can use the :latest image for now, until I write up the release notes :)