rcc: optimize compression

As the documentation says:

-threshold level Specifies a threshold level (as a percentage) to use when deciding whether to compress a file. If the reduction in the file size is greater than the threshold level, it is compressed; otherwise, the uncompressed data is stored instead. The default threshold level is 70%, meaning that compressed files which are 30% or less of their original size are stored as compressed data.

It seems kindof a high bar; maybe 50% or less would be a better general rule of thumb, more achievable by typical compression algorithms, so that more data is compressed by default. The result seems to be that QML often doesn't hit the threshold; but QML is designed to be human-readable more than compact, so it's hard to believe that it would not benefit from compression. The application or library might be installed on mobile devices where storage space is limited, so it seems that we should try harder by default, assuming the CPU cost is negligible. (I suspect that parsing and instantiating objects will take much more time than decompression.)

Another thing about QML is that each file tends to contain a lot of the same stuff: license headers, import statements, setting width and height and anchors of various items, etc. If the compression looked at all the files together, it would find some of this repetitiveness and probably would compress better than if it just looks at one QML file at a time. So it would be nice to have a shared huffman table or something like that. Or does the zip algorithm as used in rcc already do that?

Finally we could try to use a more modern algorithm than zip. LZMA is one of the better ones at the moment. It would be nice to choose an algorithm which facilitates looking at the entire corpus of QML to be compressed all at once, while still keeping each file as a separate resource.