Add argument to explicitly enable progress bar output

[GeorgeNikitinNV]

Problem: after v0.3.0 progress bar is not displayed if dorado is run not from tty.

Solution: added additional argument to explicitly enable progress bar output, not displayed if omitted:

Optional arguments:
...
  -p, --enable-progress-bar     Enable progress bar output to stderr 
...

[GeorgeNikitinNV]

Not sure why the tests failed, on my machine everything is fine:

❯ ctest --test-dir cmake-build                        
Internal ctest changing into directory: /Users/george.nikitin/dev/dorado/cmake-build
Test project /Users/george.nikitin/dev/dorado/cmake-build
    Start 1: dorado_tests
1/1 Test #1: dorado_tests .....................   Passed  108.46 sec

100% tests passed, 0 tests failed out of 1

Total Test time (real) = 108.52 sec

Also have no clue how to force checks to restart - should I make another commit for that?

[GeorgeNikitinNV]

Anyone?

[tijyojwad]

looks like the checks passed now? I think there's some intermittency in the GitHub builds based on how much disk space the test job gets

[GeorgeNikitinNV]

yes, they do

[iiSeymour]

@GeorgeNikitinNV the diff has your CMakeCache.txt included plus some submodules deltas.. might be easier to resubmit a new request from the head of master.

[palakpsheth]

would LOVE to see this PR get merged before the next release!

@GeorgeNikitinNV

[Shians]

This would be very useful for me, I run Dorado on a HPC environment and it'd be very useful to know how it's progressing.

[claczny]

One intermittent workaround could be to print a bit more verbose output (dorado basecaller -v) and then run grep -c "Load reads from file". Of course, one would have to get the total number of pod5 files to know how far the process is.
This would not resolve on the level of reads basecalled but pod5 files processed. If there is only one pod5 file that contains all reads, it is not very informative.
Hence, having a read-level progress output would indeed be very useful.