Fix URL joining for non-HTTP schemes (s3://, file://, etc.)

[jezdez]

Summary

Python's urllib.parse.urljoin doesn't handle non-HTTP URL schemes properly. When joining an s3:// URL with "." or "", it returns just "." instead of the original URL with a trailing slash. This caused package URLs to be malformed (e.g., .zlib-1.2.11-h7b6447c_3.tar.bz2 instead of the full S3 URL).

This PR adds a _safe_urljoin_with_slash() helper function that:

• Uses standard urljoin for HTTP/HTTPS (works correctly)
• Handles s3://, file://, ftp://, and other non-HTTP schemes manually
• Always returns URLs with trailing slash for proper filename concatenation

Changes

• Added _safe_urljoin_with_slash() helper in shards.py
• Updated ShardBase.base_url property to use the new helper
• Updated _shards_base_url() function to use the new helper
• Added parametrized tests covering HTTP, S3, file, and FTP URL schemes

Alternative considered

An alternative fix would be to register the s3 scheme with urllib.parse globally:

from urllib.parse import uses_netloc, uses_relative
uses_netloc.append("s3")
uses_relative.append("s3")

This makes urljoin work correctly for S3 URLs. However, this approach was rejected because:

1. Global side effects: Modifies urllib.parse behavior for all Python code in the process, not just conda/cls
2. Behavioral changes: Changes urljoin results significantly (e.g., urljoin("s3://bucket/path", "file.txt") changes from "file.txt" to "s3://bucket/file.txt")
3. Potential breakage: Other libraries might (incorrectly) depend on the current behavior

The local _safe_urljoin_with_slash() helper is safer as it only affects the specific code paths that need fixing.

Fixes #866

[dholth]

This isn't urljoin's longer list?

[jaimergp]

Wouldn't it be simpler to replace the scheme with http if it's something else, and then undo?