Fixes an unexpected performance regression in SpectrumView

[crsib]

After merging the spectrum brush branch - a new hot path was accidentally added to spectrum rendering.

1. std::round is expensive as is. The implementation is complex and designed to handle different situations.
2. By mistake the following chain was introduced: round(float)->int->double->round(double)->int

The new implementation uses lrintf. By default, it rounds to nearest, and ties are rounded to even. This does not match the behavior std::round entirely, but given that it only slightly affects the visuals, that shouldn't be a problem

Resolves: (direct link to the issue)

(short description of the changes and the motivation to make the changes)

• I signed CLA
• The title of the pull request describes an issue it addresses
• If changes are extensive, then there is a sequence of easily reviewable commits
• Each commit's message describes its purpose and effects
• There are no behavior changes unnecessary for the stated purpose of the PR

Recommended:

• Each commit compiles and runs on my machine without known undesirable changes of behavior

[Paul-Licameli]

The original std::round by Edward is replaced by lrintf which should make a difference only with exact values at the halves, and I don't care how the difference affects the display.

Rounding values that were already rounded was a supid mistake of my own!

[crsib]

Rounding values that were already rounded was a supid mistake of my own!

What is stupid is how std::round is defined for the integers:

A set of overloads or a function template accepting an argument of any integral type. Equivalent to 2), 6), or 10), respectively (the argument is cast to double).

I would expect it to be noop