bk build being too trusting about filenames

Start by reproducing the bk build failure with the Flyway YAML example and trace the download and archive-unpacking flow. Identify where the downloaded filename and unpack destination are chosen; done means this redirecting Maven URL no longer causes the download path to collide with the directory being unpacked.

if we have

distributable:
  url: https://search.maven.org/remotecontent?filepath=org/flywaydb/flyway-commandline/{{version.raw}}/flyway-commandline-{{version.raw}}.tar.gz
  strip-components: 1

we get an error:
AlreadyExists: File exists (os error 17): mkdir '~/pantry/srcs/flywaydb.org-10.10.0'
because the file downloads as flywaydb.org-10.10.0.

i was assuming it was trusting the server about the filename, but it doesn't seem like that's the case:

$ curl -LI 'https://search.maven.org/remotecontent?filepath=org/flywaydb/flyway-commandline/10.10.0/flyway-commandline-10.10.0.tar.gz'
HTTP/1.1 302 Moved Temporarily
Date: Thu, 14 Mar 2024 18:50:56 GMT
Content-Type: text/html
Content-Length: 138
Connection: keep-alive
Server: nginx
Location: https://repo1.maven.org/maven2/org/flywaydb/flyway-commandline/10.10.0/flyway-commandline-10.10.0.tar.gz
X-request_uri: /remotecontent?filepath=org/flywaydb/flyway-commandline/10.10.0/flyway-commandline-10.10.0.tar.gz
X-query_string: filepath=org/flywaydb/flyway-commandline/10.10.0/flyway-commandline-10.10.0.tar.gz

HTTP/1.1 200 OK
Connection: keep-alive
Content-Length: 111526803
ETag: "e8a43977b1a9d667414c8c74c82494de"
Content-Type: application/x-gzip
Last-Modified: Thu, 14 Mar 2024 10:36:34 GMT
X-Checksum-MD5: e8a43977b1a9d667414c8c74c82494de
X-Checksum-SHA1: ef0c8c3aacb8fd541864050bc11f8c6a61a50158
Via: 1.1 varnish, 1.1 varnish
Accept-Ranges: bytes
Age: 18223
Date: Thu, 14 Mar 2024 18:50:56 GMT
X-Served-By: cache-iad-kjyo7100084-IAD, cache-bos4634-BOS
X-Cache: HIT, HIT
X-Cache-Hits: 12, 0
X-Timer: S1710442257.604597,VS0,VE1

still, it's getting downloaded to the same path we want to unpack to, which is causing problems.