Improve handling of numeric output type IDs.

[annakrystalli]

Resolves #54 & #58 (+ related discussion in #59)

Rationale behind fix:

I think I came up with a solution to the issues we were having with trailing zeros in tasks.json output type IDs as well the high precision floating point issues identified by @elray1 in #58 . When the output type id column is character, it involves coercing any type IDs associated with a numeric output type to numeric and then back to character. This takes care of trailing zeros or high precision values (much like what happens in expand grid) so everything matches nicely, follows the rationale that for numbers trailing zeros are meaningless and that they are generally compared using tolerances (rather than exact matches). The conversion to numeric creates a representation that gets rid of any high precision tolerances and the conversion back to character means values can be compared for exact matches. I wouldn't call it particularly elegant but it seems to be working.

However though is required on any downstream implications. Currently, the 0.1000000000000000055511 value @elray1 introduced to demonstrate behaviour would match a 0.1 quantile value and pass validation. We would need to check this doesn't affect ensembling downstream. A similar conversion might be required there too to ensure matching.

Also fixes the bug reported by European flu-forecast-hub and improves execution error message capturing.