Loosen search iterator

[CiaranOMara]

This PR loosens the Search iterator to accommodate iterating in forward and reverse directions.

It needs a little more work to support the ApproxSearchQuery. It wasn't immediately obvious how to have the iterator generically include or pass through additional arguments to an underlying function. The other approach is to have ApproxSearchQuery own the additional argument for the number of allowed errors - comments would be helpful.

Let me know whether this seems like a good direction for a search iterator.

[codecov]

Codecov Report

❌ Patch coverage is 50.00000% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.39%. Comparing base (d3d8fc4) to head (a9d1355).
⚠️ Report is 80 commits behind head on master.

Files with missing lines	Patch %	Lines
src/BioSequences.jl	50.00%	5 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #221      +/-   ##
==========================================
- Coverage   88.74%   88.39%   -0.35%     
==========================================
  Files          31       31              
  Lines        2425     2430       +5     
==========================================
- Hits         2152     2148       -4     
- Misses        273      282       +9     

Flag	Coverage Δ
unittests	88.39% <50.00%> (-0.35%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[TransGirlCodes]

That seems very desirable to me, I remember thinking looking at the search code - "hmm how would you make Approx go backwards?".

[CiaranOMara]

The Search iterator would become generic or complete in its current state if all the queries owned their additional arguments. However, changing ApproxSearchQuery is a breaking change. So a design discussion is needed (hence converting this PR to draft).

I think we would be in a better position if we constrain our findnext and findprev method signatures to the following.

function findnext(query, seq::BioSequence, start::Integer)
    ...
end

function findprev(query, seq::BioSequence, start::Integer)
    ...
end

All the peripheral findfirst, findlast, findall methods can become generic if we adopt this constraint.

In terms of the ApproxSearchQuery, it would need to adopt the additional k argument somehow, and perhaps another wrapper/layer may be required to optimise for the reuse of ApproxSearchQuery's work.