Update average run time

[ErikSchierboom]

There are two reasons for this change:

1. Having the average run time as a float gives the impression of being exact, whereas the actual run time wildly varies due to a wide variety of reasons (e.g. how busy it is on the server). That fractional component will almost never actually conform the real situation.

2. jq is often used to work with track config.json config files (e.g. to add elements to it), and it will remove any trailing .0 fractional part from a number, which caused configlet lint to fail. Those JQ scripts then have to work around this by manually adding .0 to it.

[ee7]

Also, when configlet fmt supports the track-level config.json file, this PR raises the questions:

• should configlet fmt exit non-zero when the value is an int?
• when -u is passed, should configlet fmt rewrite e.g. 5 as 5.0, or vice versa?

The answer to both questions should be the same, because configlet fmt -u should only format things that configlet fmt complains about.

So we have two options:

• Both answers are "no", then configlet fmt has to parse e.g. 5 as a float, but later remember that it was previously an integer, and not write it as 5.0. That's awkward.
• Both answers are "yes", then there's a de-facto canonical representation of average_run_time as either a float or an int. I expect that eventually most tracks will enable configlet fmt in CI, which means there's no benefit on being lenient in configlet lint anyway - it'll still fail CI. And it's worse, because the user only sees the problem at CI-time, not when running configlet lint locally before making a PR.

Things are simpler if the type of everything is known at compile time. So I think this PR isn't worth it. Thoughts?

[ErikSchierboom]

that requires an Exercism-wide PR, which probably isn't worth our time.

Well, why not? Should be easy enough.

if a track gets down to very low average run times, the difference between e.g. 1.0 and 1.5 may be meaningful enough.

It won't be though, as there are many other factors that influence the average run time, like how crowded our servers are. People won't notice a difference of half a second.