Changes

pod: use `coreos-ci-sa` serviceAccount when using `runAsUser`

That service account has `RunAsAny` caps.

This is a bit hacky. Ideally, this shared lib wouldn't hardcode things
specific to either CoreOS CI or the pipeline here and instead we'd store
this config in https://github.com/coreos/coreos-ci. This works though
because the FCOS pipeline doesn't use `runAsUser` at all.

pod: use serviceAccountName instead of serviceAccount

The latter is deprecated. It should still work at the k8s level, but
it's possible there's something going on with the Jenkins kubernetes
plugin not handling this correctly.

pod: set serviceAccount in podTemplate instead of YAML

Setting the `serviceAccountName` field in the pod YAML itself is not
working with the kubernetes plugin. I noticed that `podTemplate` also
supports specifying the `serviceAccount` directly. It's possible that
that key is used and any service account set in the pod YAML directly is
always overridden.

Let's try using that instead.

Move from Quay.io to app.ci

The latter mirrors to the former, but it's a periodic that runs every
hour. So let's just use the images directly from app.ci for faster
iteration.

buildImage: add support for setting memory and cpu

In cosa CI, we're hitting:

> runtime: failed to create new OS thread

I think this is another instance of non-Kubernetes-aware multiprocessing
like in https://github.com/coreos/coreos-ci/issues/23.

Let's expose the `resources` knob for building images like we already do
for `pod`. This will allow us in cosa to request a specific amount, and
then asking golang to respect it.

buildImage: fix resource request

We need to initialize the maps before we can set keys inside.

Fixes decacbc ("buildImage: add support for setting memory and cpu").