Add unprotected output switch to keepassxc-cli extract

[Z1ni]

Provides a way to output unprotected database XML when using keepassxc-cli extract.
As seen in #2164

Description

Added a new switch -u / --unprotected.
The implementation writes the database to a QBuffer using a KdbxXmlWriter without specifying a random stream, which causes the KdbxXmlWriter::writeEntry to write the plaintext value.
This QBuffer is then returned as a string containing the non-protected XML.

Motivation and context

#2164

How has this been tested?

Tested with a clean install of Ubuntu 18.04 and with a new database that contains protected values (passwords, custom attributes etc.).
When not using -u, the output will have protected fields. When using -u, the protected fields are unprotected and do not contain the Protected attribute.

Screenshots (if appropriate):

Types of changes

• ✅ New feature (non-breaking change which adds functionality)

Checklist:

• ✅ I have read the CONTRIBUTING document. [REQUIRED]
• ✅ My code follows the code style of this project. [REQUIRED]
• ✅ All new and existing tests passed. [REQUIRED]
• ✅ I have compiled and verified my code with -DWITH_ASAN=ON. [REQUIRED]
• ✅ My change requires a change to the documentation and I have updated it accordingly.

[droidmonkey]

This may conflict with #2351

[Z1ni]

This may conflict with #2351

It seems that #2351 implements decrypted XML output as the default and only way to export the data.
Maybe it would be better to let the user explicitly indicate if they want the protected fields to be in plaintext? One use case that comes in mind is if some utility wants to do some kind of "metadata" listing without protected data.

I guess that this PR can be closed then (assuming that the other PR gets merged).

[phoerious]

There is no way to decrypt the protected values, because the key is stored on the kdbx header. And yes, this will conflict with my PR.

[phoerious]

Closing this, since it's conflicting and a solved problem. If you disagree, please voice your concern sternly and firmly.