Fix size calculation for containers without sizeable children [COMPOSER-2086]

[achilleas-k]

The Container size calculation is meant to calculate the size of all the
children of a Container + any metadata in order to:

1. Ensure the size of the container itself is big enough, if it is a
   Sizeable.
2. Send the new desired size up the branch for the ancestor Entity
   calculations.

A problem occurs when a Container doesn't have access to the size
information of its descendants. The child size sum is 0, so the
container size is calculated as only the size of any metadata it
requires.

This occurs in the case of a LUKS container with an LVM Volume Group in
it. The LUKS container's child size calculation is 0, the containerSize
is therefore just the MetadataSize() of the LUKS container and so no
decision is made to resize because the containerSize (which is just
MetadataSize) is always smaller than the desired size (which is actually
the size of the children of the VolumeGroup calculated by the previous
recursive execution of the function).

Fix this by detecting when the children size calculation is 0 and
setting the containerSize to the desired size instead.

This changes the logic of the function a bit when it's called directly
on such a container. If we now call
resizeEntityBranch(pathToLUKS, size)
the parent of the LUKS container will be resized to size + 16 MiB (the
LUKS metadata size). This makes sense in our context, because it
ensures that the partition has enough space for 'size' data + the LUKS
metadata.

[supakeen]

Neat. (Container is such an overloaded term).

[achilleas-k]

Neat. (Container is such an overloaded term).

Yeah and naming is HARD!

[say-paul]

I tested it against my PR, all green here.

[thozza]

Nice catch and great work 👏

I found just one typo, otherwise, this is great 😍