Correct trigger channel indexing while reading AcqKnowledge files.

[smoia]

Closes #272, although the fixed problem is not the same - still, thanks @tsalo!

Turns out the algorithm was meant to extract the channel after the one of the trigger since we modified phys2bids to have -chtrig human-friendly (rather than pythonic).

Proposed Changes

• the chtrig index is lowered by one in place when extracting the timeseries from the trigger channel.
• the docstring now indicate that chtrig is meant to represent an index starting from 1.

[codecov]

Codecov Report

Merging #275 into master will decrease coverage by 0.10%.
The diff coverage is 75.00%.

@@            Coverage Diff             @@
##           master     #275      +/-   ##
==========================================
- Coverage   93.61%   93.51%   -0.11%     
==========================================
  Files          10       10              
  Lines         861      863       +2     
==========================================
+ Hits          806      807       +1     
- Misses         55       56       +1     

Impacted Files	Coverage Δ
phys2bids/cli/run.py	96.55% <ø> (ø)
phys2bids/phys2bids.py	86.06% <50.00%> (-0.45%)	⬇️
phys2bids/interfaces/acq.py	100.00% <100.00%> (ø)

[tsalo]

The CLI's docstring and default value for chtrig also indicate zero is the first channel. I would update those as well as add a check for either the parser's chtrig parameter or at the beginning of the phys2bids Python function to ensure that the chtrig value is an integer greater than or equal to 1.

[vinferrer]

LGTM!!! althought remmeber bugs PR only need one reviewer, you can merge already

[tsalo]

@vinferrer I didn't realize that the physiopy community classified PRs like that, but that's awesome! In the docs, though, it looks like two reviews are currently required for bug fixes. Perhaps that needs to be updated?

2. Have the necessary amount of approving reviews, even if you’re a long time contributor. You can ask one (or more) contributor to do that review, if you think they align more with the content of your PR. You need one review for documentation, tests, and small changes, and two reviews for bugs, refactoring and enhancements.