Issue #750 - Introduce a `forecast_type` argument in `validate_forecast()`

Description

As discussed in #750, it would be nice to have a way in validate_forecast() to check the type is exactly what you want.

This PR therefore

introduces a forecast_type argument in validate_forecast(), analogously to the one that already exists in as_forecast().
creates a new function, assert_forecast_type() that does exactly that, simplifying the code in as_forecast() and minimising repetitive code in validate_forecast(). The rationale for the slightly odd design with actual and desired is that that avoids running get_forecast_type() again in situations where the forecast type is already determined by the class of the object. An earlier version only had a single argument forecast_type() for the desired type and the actual type was determined automatically. This, however, presumes that validation works. I think both versions are fine if you have a preference 🤷
creates a new test

[x] My PR is based on a package issue and I have explicitly linked it.
[x] I have included the target issue or issues in the PR title as follows: issue-number: PR title
[x] I have tested my changes locally.
[x] I have added or updated unit tests where necessary.
[x] I have updated the documentation if required.
[x] I have built the package locally and run rebuilt docs using roxygen2.
[x] My code follows the established coding standards and I have run lintr::lint_package() to check for style issues introduced by my changes.
[ ] I have added a news item linked to this PR.
[ ] I have reviewed CI checks for this PR and addressed them as far as I am able.