Bump dependencies to formats-bsd 6.10.1 and jzarr 0.3.5

[sbesson]

Discovered while reviewing the dependency conflict https://github.com/glencoesoftware/NGFF-Converter

This change aligns the dependencies of raw2ometiff with the ones used in bioformats2raw 0.5.0

Should be amenable for an immediate patch release 0.3.2 as there is no functional or API change

[sbesson]

* What went wrong:
Execution failed for task ':compileJava'.
> Could not resolve all files for configuration ':compileClasspath'.
   > Could not download httpservices-5.3.3.jar (edu.ucar:httpservices:5.3.3)
      > Could not get resource 'https://nexus.senbox.net/nexus/content/groups/public/edu/ucar/httpservices/5.3.3/httpservices-5.3.3.jar'.
         > Could not GET 'https://nexus.senbox.net/nexus/content/groups/public/edu/ucar/httpservices/5.3.3/httpservices-5.3.3.jar'.
            > peer not authenticated

is identical to the build failure on the HEAD of the base branch - see https://ci.appveyor.com/project/gs-jenkins/raw2ometiff/builds/44910893

This makes me wonder whether I should revert #83 and/or if we should declare a more suitable repository under HTTPS that serves these artifacts. For comparison, https://github.com/glencoesoftware/bioformats2raw/blob/v0.5.0/build.gradle is not using senbox. Thoughts @melissalinkert ?

[melissalinkert]

I think switching senbox to https://artifacts.glencoesoftware.com/artifactory/unidata-releases is fine.

Upgrading jzarr will also require changes in the tests, since the getNested() API in jzarr 0.3.3-gs-SNAPSHOT is being used.

[sbesson]

@melissalinkert pushed. In addition to updating the tests, I also had to bump the version of bioformats2raw used for testing to 0.5.0 to be compatible with the jzarr version used by the library.

With bioformats2raw 0.5.0 behind us, I think makes sense to test the conversion pipeline using bioformats2raw 0.5.x but that means we are no longer testing the compatibility with data generated by bioformats2raw 0.3.x. Happy to discuss if we believe this is creating a testing gap we should address.

[melissalinkert]

I had intended to bump bioformats2raw to 0.5.0 anyway as part of adding tests to #82, so this is fine with me.

@chris-allan may feel differently, but I'm not particularly worried about continuing to test with bioformats2raw 0.3.0. We have released versions of raw2ometiff that are known to work with that data, and there isn't really any advantage to upgrading raw2ometiff out of step with bioformats2raw.

[chris-allan]

I'm not particularly worried about continuing to test with bioformats2raw 0.3.0. We have released versions of raw2ometiff that are known to work with that data, and there isn't really any advantage to upgrading raw2ometiff out of step with bioformats2raw.

Agreed.