Small fixes for issues we encountered during the 0.8.0 release

[apyrgio]

This PR tackles the following minor issues:

1. Make the dz qube larger, now that we ask users to download Tesseract data. Initially the /home disk size was 2GiB, and with this change, we bump it to 5GiB.
2. Remove a reference to a second container from our README.
3. Update our QA script to implement two more steps from our instructions.

[apyrgio]

@deeplow: One quick question about 8f8252e. I haven't found a way to create an app qube and define the disk size at the same time, hence the separate command. Do you know of a more canonical method?

[deeplow]

As far as I'm aware qube creation is solely done by the qvm-create and qvm-clone commands and they don't allow for control of volume creation other than where it will be created. So it has to be a separate command. Also, I don't think it being exactly 5GiB is strictly necessary, but it does not harm (other than a longer commmand).

[deeplow]

An additional potential improvement (which I haven't checked if it exist or not) would be to check if there is enought space available before downloading tesseract data. This could be helpful also on non-Qubes systems.

It will be really nice when this turns into a multiVM application (kind of like SecureDrop) where updates also happen at the Qubes-level, so that the user doesn't have to keep reconfiguring the system. But that's a longer effort, especially because the installation and update story is not very polished yet.

update: never mind. I thought I was looking at the INSTALL instructions and not the BUILD (a.k.a. dev-facing ones). There's of course no need to build guard-rails for those. But this reminded me that there may be challenges getting dynamically downloaded OCR languages (#488) to work on Qubes. I'll write on the respective ticket (DONE).

[almet]

This looks good to me, except some of the comments I added, but they're mainly about readability.

[almet]

Thanks, looks good. I've added a small nitpick, do what you want with it :-)