Goal
After a f2f discussion with @jbracher, there are two paths to estimate the uncertainty. Method 1 involves iteratively re-estimating the delay distribution for $M$ different retrospective reporting triangles and re-computing point nowcasts from each new delay, using $N$ past observations. This is what is performed in the RESPINOW codebase. Method 2 involves iteratively re-computing the point nowcasts, using the a specified delay distribution (that would be constant).

Currently, we have Method 2 implemented, we likely want to all for both, with one of the two being a reasonable default (as many users may not be aware of the different assumptions involved in each).

Describe the solution you'd like

• modify estimate_uncertainty() to only optionally take in a delay_pmf. If the user does not pass the delay_pmf, method 1, which relies on re-computing it, will be used. If they pass it in, method 2 will be used.

Describe alternatives you've considered
Could just stick with method 1, if we want to be completely consistent with RESPINOW codebase, but after discussions seemed like it is useful to have both options, because of the delay distribution being used is misspecified/ inaccurate due to borrowing from a different strata, we would actually want that expected amount of error in our error estimate.

Additional context
@seabbs had suggested in #18 that we allow the user to pass in multiple triangles and enable uncertainty estimates from multiple triangles (my guess would be using either method 1 or 2 described above). Is this a good place to expand to include that functionality?