Issue 160: Add ObservationErrorModel type and functions

[seabbs]

This PR proposes an approach for resolving #160 by introducing a new AbstractTuringObservationErrorModel and associated generic methods.

Before making this a full PR I need to:

• Add documentation for new methods
• Add tests for abstract methods
• Decide if pos_shift can live in the generic as a hard-coded value.
• Decide if we want a EpiAwareBase set of abstract types.

Note that this approach also suggests a modifier wrapper (i.e AbstractObservationModifierModel) and also suggests this branch/leaf setup elsewhere (i.e latent models) but this can be discussed here and acted on via other issues. It may just be infra we don't currently need IMO.

This now extends #267 and updates handling of latent delays so that missingness is instead concatenated into the beginning of the vector and the internal obs error model detects this and only starts fitting. To get this working I needed to stop using undef when y_t = missing which has required changing some of the tests. This fix is still not ideal but it at least preserves the input out of the model.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 90.00000% with 3 lines in your changes missing coverage. Please review.

Project coverage is 92.84%. Comparing base (8e8bf26) to head (28182b3).

Files	Patch %	Lines
...src/EpiObsModels/ObservationErrorModels/methods.jl	76.92%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #268      +/-   ##
==========================================
- Coverage   93.40%   92.84%   -0.57%     
==========================================
  Files          45       46       +1     
  Lines         455      461       +6     
==========================================
+ Hits          425      428       +3     
- Misses         30       33       +3     

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

[seabbs]

@SamuelBrand1 do you have thoughts about the outstanding questions ?

[SamuelBrand1]

@SamuelBrand1 do you have thoughts about the outstanding questions ?

Re: Base types. The upside of having the abstract types in EpiAwareBase is that we are providing the type tree for people to create concrete subtypes for. Given that we have fairly specific abstract types there e.g. AbstractTuringIntercept then I think AbstractTuringObservationErrorModel can live there too?

[SamuelBrand1]

Decide if pos_shift can live in the generic as a hard-coded value.

I'm agnostic on this.

[SamuelBrand1]

This is looking good so far; conditional on

This fix is still not ideal but it at least preserves the input out of the model.

[seabbs]

I'm agnostic on this.

We need to make a decision. Is it important too be able to customise/turn off. If its not it can go in the abstract type. If we can implement it so that you can still do so it can also go in the abstract type.

[seabbs]

This is looking good so far; conditional on

Conditional on which part?

[SamuelBrand1]

This is looking good so far; conditional on

Conditional on which part?

That this is probably (? Idk I haven't thought of a better approach yet) not ideal but it fixes my problem with #267 .

[SamuelBrand1]

I'm agnostic on this.

We need to make a decision. Is it important too be able to customise/turn off. If its not it can go in the abstract type. If we can implement it so that you can still do so it can also go in the abstract type.

This is not important to customise.

[seabbs]

@SamuelBrand1 this is ready for review. I have added the positive shift to the abstract generate_observations (hard coded), removed it from the error models, and moved the abstract type into EpiAwareBase.

[seabbs]

Note the reason you are being asked for a review is that I tighted branch controls to dismiss reviews when new commits are made.

[SamuelBrand1]

LGTM. I like these changes; opens up other obvious observation error models (e.g. LogNormal, Normal, TDist etc with less repetitive code/time shift reasoning.