Support Qt installer type

[BrandonWanHuanSheng]

It look like microsoft/winget-pkgs#129021 and microsoft/winget-pkgs#129015 failed with Validation-Unattended-Failed which must required NestedInstallerType: Qt and it will support in the future

[Trenly]

Why can't you just use the unattended switches?

InstallerSwitches:
  Silent: in --am --al -c
  SilentWithProgress: in --am --al -c

[Dragon1573]

But we have to download the installer file and manually inspect it if it supports -? or --help and response itself as packaged with Qt Installer Framework.

For those well-known installer type (nullsoft, wix, msi, burn, inno, ...), all creators including wingetcreate.exe, YamlCreate.ps1 and Komac can silently inspect them and contributors don't have to write these InstallerSwitches. We can do all the same thing as configuring them with InstallerType: exe and manually set all properties under InstallerSwitches according to their documentation. But we have to inspect the installer file if they are well-known installer type manually. We are making things complicated ...

Adding new installer type enum value of qt can simplify manifest creating process for contributors. We don't have to check if an installer file is packaged with Qt Installer Framework manually any more.

[Dragon1573]

When the package is huge, it may become an awkward problem for some contributors who have poor network connections, as they have difficulties downloading the file to their local devices.

GitHub Codespace can sometimes handle this problem when installer file type is well-known and can be inspected by Komac. However, Codespace only provides Ubuntu instance so we can't run installer manually in it and see if the installer file support unattended installation (and also with what switches).

If there's an existing third-party tool which can used in Codespace (or local device) and able to detect the packaging technology of the installer file, it might be a walkaround for us.