Resolve a couple of issues around azure blob storage support

[okhaliavka]

Fixes #3044
Resolves #3167

Description
There's currently a number of issues with Azure support in kaniko.

#3044 is a bug that makes kaniko completely unable to download build context from Azure Blob Storage, which was probably introduced in 16ed6b2.
When constructing a blob storage client, kaniko is passing an entire context url (e.g. https://accname.blob.core.windows.net/bucket/context.tar.gz) where just an account url (https://accname.blob.core.windows.net/) is expected. As a result, the bucket/context.tar.gz part gets duplicated in the final URL and the blob doesn't get found.

#3167 is rather a usability concern about kaniko requiring users to provide a storage access key as an env var, making it impossible to use better auth methods, such as managed workload identity. Looks like it'd be better to offload authentication to the azidentity library and use the default azure credential chain, letting users decide on the appropriate way to provide storage credentials for kaniko.
To keep things backward-compatible, the existing auth method will be kept and still attempted first. But when an access key is not provided, kaniko will fallback to the default credential chain, instead of immediately failing with an error.

I'm aware that this project is pretty much abandoned, but I still have a tiny glimmer of hope that this contribution will be reviewed 😅 .

Submitter Checklist

Azure blob storage isn't covered by unit/integration tests. Fixing that would require more time that I'm willing to put without any certainty that this PR has a chance to be reviewed and merged.

• Includes unit tests
• Adds integration tests if needed.

Reviewer Notes

• The code flow looks good.
• Unit tests and or integration tests added.

[okhaliavka]

to be split into separate prs