Expose resample_filter optional arguments in resample, FIRFilter

[wheeheee]

Just passes on arguments in the most obvious manner.
Additionally, make some FIRKernel fields const, and removed unnecessary @inbounds, and added restrictions to pad_length in filtfilt to prevent oob.
Also wrote some minimal documentation for resample_filter. Need some help here, I just guessed the meaning of rel_bw...

Should help with #620

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.12%. Comparing base (06f8776) to head (0148012).

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #621      +/-   ##
==========================================
+ Coverage   97.97%   98.12%   +0.15%     
==========================================
  Files          19       19              
  Lines        3254     3258       +4     
==========================================
+ Hits         3188     3197       +9     
+ Misses         66       61       -5     

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

[martinholters]

Mostly LGTM, but if the missing coverage reports are legitimate, some more tests are in order.

[martinholters]

How do you feel about bumping the version to 0.8.1 as part of this PR and tagging a new release once it's in?

[wheeheee]

How do you feel about bumping the version to 0.8.1 as part of this PR and tagging a new release once it's in?

Sure, why not.

Also, do you think rel_bw and attenuation should be keyword arguments? Makes it harder to accidentally mess up.

[martinholters]

Ooof, +343 -267 lines for a relatively simple change due to code reorganization and tangential changes. That really makes code review unnecessarily hard. I'll try to find time/motivation for a closer look at this, but if you get impatient, you could help by moving NFC changes like the introduction of reference data or the like to separate PRs.

[martinholters]

A few tests are redundant/pointless on 32bit systems. Not sure how much we should care, but can easily be fixed. Otherwise LGTM.

[wheeheee]

How do you feel about bumping the version to 0.8.1 as part of this PR and tagging a new release once it's in?

Should we bump here or after #623?

[martinholters]

How do you feel about bumping the version to 0.8.1 as part of this PR and tagging a new release once it's in?

Should we bump here or after #623?

Hm, AFAICT #623 doesn't do anything worth postponing a release for. OTOH, review and merge of #623 should be relatively quick once it's rebased, so ... I don't know. Your call.

[wheeheee]

After that, then.