container: Add application layer to the correct end of the layer stack

[euanh]

Motivation

containertool currently adds the app layer to the beginning of the
layer stack array in the manifest. This results in the app layer
being the first to be unpacked, with the others stacked on top. We
can show this by adding a plain text file as the executable. If we
stack another layer on top with a file of the same name, it should
replace the underlying one but it does not:

echo first > bar
swift run containertool --repository localhost:5555/bar bar
podman run --pull=always -it --rm --entrypoint=cat localhost:5555/bar:latest bar
# prints: first

echo second > bar
swift run containertool --repository localhost:5555/bar bar --from localhost:5555/bar:latest
podman run --pull=always -it --rm --entrypoint=cat localhost:5555/bar:latest bar
# prints: first
# should print: second

Currently containertool is only used to add the application binary
to the application layer. This bug will only cause a problem if the
base layer adds a binary at the same path, because this will override
the application.

This bug probably arose because the specification for the rootfs.diff_ids
field of the image configuration defines the layers as being "in
order from first to last", which could be read ambiguously:
https://github.com/opencontainers/image-spec/blob/main/config.md?plain=1#L220-L222

The specification for the manifest.layers field is much more explicit
about the ordering:
https://github.com/opencontainers/image-spec/blob/fbb4662eb53b80bd38f7597406cf1211317768f0/manifest.md?plain=1#L70-L71

Modifications

Append the application layer to layer stacks in the manifest and configuration blobs, instead of prepending.

Result

This with this change, the second build and container run in the
example above prints "second" as expected.

Test Plan

This PR adds a new integration test which uses containertool to build two layers and check that they override each other correctly.

All existing tests continue to pass.

Fixes #57