Coursier fetch fails rarely for authenticated Maven repos: no such package '@maven//'

coursier_fetch() fails for a very small minority of users for authenticated Maven repositories with this output:

_ERROR: An error occurred during the fetch of repository 'maven':
unsupported operand type(s) for +: 'string' and 'NoneType'
ERROR: no such package '@maven//': unsupported operand type(s) for +: 'string' and 'NoneType'_

At least with the Sonatype Nexus product, user tokens are Base64 encoded and therefore slash '/' character is legal. For the greatly misfortunate (me!) that means the primary url can look something like this assuming the hashed user token is 'abcdef/':

https://abcdef/@our-nexus-server.demo.com/nexus/content/groups/public/com/google/code/findbugs/jsr305/3.0.2/jsr305-3.0.2.jar

That trailing slash on the username 'abcdef/' breaks the logic here which is not expecting a slash in the username:
https://github.com/bazelbuild/rules_jvm_external/blob/master/coursier.bzl#L415

since the first token in the split() list is expected to be 'username@host':
https://github.com/bazelbuild/rules_jvm_external/blob/master/coursier.bzl#L426

but instead element 0 is just the poor user's username that precedes the slash in the username:
_abcdef_

Read coursier.bzl around lines 415 and 426, focusing on how authenticated Maven repository URLs are split. Reproduce coursier_fetch() with a Base64-encoded username containing a slash, such as `abcdef/`, and verify that fetching the shown artifact no longer fails with the NoneType error.

Written by the indexing model from the issue text.