When Kafka Connect Build is downloading artifacts, it is currently using the last segment of the URL as a filename. However, as discussed in #5117 this does not really work in all cases. For example with he download URL https://drive.google.com/uc?export=download&id=1sEZHDMskmwV31vTx7nUI_yoJM7AgdpXX, the resulting file name is uc?export=download&id=1sEZHDMskmwV31vTx7nUI_yoJM7AgdpXX which is not valid.

The easy fix is to use the URL hash as the file name. This is already used to create the directories where the files are added. This works without issues for ZIP and TGZ archives where the files are anyway just temporary and are deleted after unpacking. It works also for JARs which can be named <hash>.jar.

But type: jar artifacts are also used to simply download and place any file. This could be for example an so library (used by some Debezium connectors as an example) or it could be a LICENSE file etc. Naming them <hash>.jar makes little sense and does not work. therefore this PR adds a new artifact type other. This an be used to download assorted artifacts without any expectation of a file type. Optionally, user can also specify fileName option for this type of artifact which will be the name of the file used in the target image. For example:

- fileName: my-db-driver.so
  type: other
  url: https://some-url.tld/downaload?artifact=12334&path=some/random/path&someOther=option  

 If the fileName is not specified, the file will be simply named <hash> based on the URL hash. This should fix the issue with weird file names causing errors.
The downside is that any user who currently uses type: jar artifact to download a file under some specific name will now experience a change which might break his deployment and might need to change the CR to use the type: other}}artifact. The alternative options to this would be to leave this unfixed for {{type: jar artifacts. But this seems like a cleaner way to go for the future.