Include source of invalid base64 data in error messages

[tjkirch]

Description of changes:

Include source of invalid base64 data in error messages
    
The user data content could be sensitive.

Note for host-containers/bootstrap-containers: we don't save the output of restart-commands (including host-containers) today, so this is just to make sure we don't forget this if we do start to save it later.

Note for all of them: these shouldn't even be possible to hit with today's API protections, so again it's just being safe; see testing note...

Testing done:

These have the same problem, in that it's not really possible to hit the "invalid base64" error case without removing a bunch of protections in apiserver. The base64 has to be valid to be accepted in the first place, and has to be valid later on for the apiserver to deserialize it from disk and give it to these programs. Given the tiny changes and the strengths around this, I'm not sure it's worth ripping up everything else..?

I confirmed that it builds, tests pass, an AMI worked fine, admin and control host containers still worked fine.

Terms of contribution:

By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.

[tjkirch]

^ This push cleans up everywhere we handle a base64::DecodeError to print some useful source information (like container name, template name, etc.) rather than the base64 content.