Decompose forward function into initialize, predict, update

[THargreaves]

As discussed in #104, this PR takes the existing forward filtering code and decomposes it into separate functions for initialising the filter, predicting the next state and updating the filtered state.

There are a few mildly ugly corners:

• logL is passed into _update! and returns. This is because the logL in storage is not updated until the full forward filtering is completed. This could be resolved by passing a k argument into forward! and updating logL[k] in-place but changing this signature had knock on effects on other algorithms (e.g. Baum-Welch) so I've left for now
• The prediction step is skipped for t=1 since we just use the initialisation value.

On the bright side, this decomposition has made the indexing a bit easier to understand. The loop is now t1:t2 and the main index used is t rather than t+1 before.

All correctness tests pass but there are few test cases in the AD/temporal examples that are failing. Happy to look into these but @gdalle might be able to instantly spot what's wrong.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.22%. Comparing base (38eb996) to head (6b2a3d4).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #105      +/-   ##
==========================================
+ Coverage   95.20%   95.22%   +0.02%     
==========================================
  Files          17       18       +1     
  Lines         500      503       +3     
==========================================
+ Hits          476      479       +3     
  Misses         24       24              

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

[gdalle]

@THargreaves what do you think? Are these the functions you would need to be part of the public API?

[THargreaves]

Yes, those are perfect. Thank you for making the changes!

I'm not sure if they necessarily need to be part of the public API as we'll be wrapping them to match our slightly different type signature. If that's the easiest way to make sure these methods don't change though that might be best.

[gdalle]

Indeed if it's not part of the public API then it is vulnerable to change at any second. My suggestion is that I'll first release a new version of HMMs including them as private API, that way you can experiment and see what's missing. Once your code stabilizes, we'll figure out the best way to make its ingredients public API in HMMs.

[THargreaves]

Sounds like a plan 👍