Use new bioformats2raw progress API

[melissalinkert]

This won't compile, it's just a place to start. See glencoesoftware/bioformats2raw#172.

Probably main point is whether a hard dependency on bioformats2raw is what we want. If not, that would mean either reimplementing listeners here or putting listeners somewhere else that both bioformats2raw and raw2ometiff can use.

[sbesson]

Immediate thought is that if we had an array of Java converters, I could definitely see a value proposition to migrate common utility classes into a shared upstream component. As things stand, my primary concern is that introducing a third component feels a bit overkill though and I do not see off-hand an immediate component where these would belong.

Re the introduction of a bioformats2raw dependency, I am not versed in the original decisions and whether these repositories should be kept as separate. From my side, there is de facto a relationship between bioformats2raw and raw2ometiff, if anything in terms of data layout/specification. In that sense, introducing such dependency does not feel out-of-scope.

[melissalinkert]

Final call for comments, @DavidStirling / @chris-allan. Plan to merge this on Tuesday (May 30) unless any objections.