2 decimal places for tempos

The PR is here: https://github.com/musescore/MuseScore/pull/4231

Unfortunately, this same .ui file was edited in the last commit, and my rebasing skills aren't familiar with edits on .ui files. So I closed the PR and created a new one here:
https://github.com/musescore/MuseScore/pull/4251

This time it's my goof, a typo, so I've deleted that last PR. Here is the current, hopefully correct PR:
https://github.com/musescore/MuseScore/pull/4252

...and yet again, here is the current, new PR:
https://github.com/musescore/MuseScore/pull/4253

Yes, I'm sorry about the git problems. I rebased this branch just now and there won't be any new PRs for this issue.
As for why .01bpm? I am synchronizing exported SVG scores in JavaScript. I have a couple of topics where I discuss this, maybe I should have linked to them in the original issue:
https://musescore.org/en/node/263040
and here:
https://musescore.org/en/node/278786

This specific use case is the opening non-musical measure that I use to sync with videos. Videos always have an introduction of some sort, titles being the most common thing. To get millisecond precision, which is the base JavaScript timing unit for animations, I need two decimal places in the beats per minute. 1 decimal gets you close, but not close enough.
It's a workaround really, which is why I consider the justification to be less than 100% important. I really need to design and add a feature for this, but now is not the time for me, especially since I have a functioning workaround.

To be completely explicit, here is a basic example:
At 60.00bpm 1 beat = 1 second
At 60.01bpm 1 beat = 1.00167 seconds
Even two decimal places doesn't get you to millisecond precision, but it's precise enough for JavaScript animations because it's more precise than any screen refresh rate on the planet, the highest of which (commercially) is 240hz, something like that. 60hz refresh rate = 60fps = 0.0167 seconds per frame.

Maybe now you can see why I hesitated to go into detail. Once you get me started I feel I need to finish :) It's a lot of information to justify an almost insignificant change to enable a workaround.

Actually it's synchronizing the musescore-based animations with video and audio. Audio requires far greater precision in time than video. Less data per frame, but a lot more frames. Milliseconds is a sort of in-between unit that works well for sync. As soon as I can get through this next round of merging my code with the latest master and fixing a few bugs, it will we publicly released, and I will announce it in the appropriate forum on MuseScore.

Hmm. I rushed through doing that math again just now. I probably have it somewhere far back in my spreadsheet full of notes and calcs. You're right about the decimal place! I input it wrong. Let me verify your numbers... yes. I'm still more comfortable going to two decimal places. There are slower tempos than 60bpm, and I don't want to have to worry about the precision on the front end being affected by anything on the back end. Getting this stuff to run cleanly in a browser is dicey enough. I would really like to have a duration based control here, in milliseconds or even frames at preset frame rates. Tempo to time calculations are a pain, but I have some setup already so I'm sticking with that version of the workaround.

I got my math together and if you get down to 24bpm you start to see an effect of >1 millisecond.
24bpm = 2.5 seconds per beat
23.99bpm = 2.50104 seconds per

So it is a borderline thing. I don't know too many scores that slow, and the real minimum precision is probably around 4ms. But I don't like cutting things that close.

I'm synchronizing to audio, video, and web animation streams. I need the greater precision, or at least I'd much prefer it. Does the extra precision bother you? The lack of precision bothers me. It's just 2 decimal places. I didn't think it would bother anyone.