Clarify why merging into another container is a bad idea

[timbavtbc]

Description

Just a change to the README - I tend to read 'YMMV' as 'might need some jiggling', but it's a bit more serious than jiggling. :) I think being explicit about the particular implementation details is more useful here.

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you
review them:

• [n/a] Includes unit tests
• [n/a] Adds integration tests if needed.

See the contribution guide for more details.

Reviewer Notes

• The code flow looks good.
• Unit tests and or integration tests added.

Release Notes

Describe any changes here so maintainer can include it in the release notes, or delete this block.

Examples of user facing changes:
- Made explicit in the README the main reasons for not merging into a different container.

[timbavtbc]

While I'm writing, it may be relevant to mention my particular use-case:

We're wanting to run our Teamcity CI agents in GKE/Autopilot. To build our application, the agents need more than just the plain agent, so we want to customise the image with that additional tooling. We want that customisation-build to happen in Autopilot too.

I haven't yet been able to find if there's a simple mechanism for containers running within Autopilot to launch-and-wait-for other containers also inside Autopilot, and we can't merge kaniko into the TC agent containers because unpacking the TC image overwrites the running TC agent. It seems we want our agents to launch kaniko with something equivalent to 'kubectl run' - if there's a known mechanism for achiving that within Autopilot, it would be nice to have a link to it mentioned near the Known Issues!