This makes the ordering consistent with other view modes of the
FileBrowserComponent and restores the behaviour prior to a400d3ebe0.

- added unit tests
- best performance timers used for each platform
- fixed an issue in which timer callbacks could drift

Previously, if the PathFlatteningIterator returned a line segment with
very large x or y positions, the result of
    roundToInt (iter.y1 * 256.0f)
could be incorrect, if the result was too large to fit in an int.

Using int64_t to store intermediate results, converting to int when
updating the edge table itself produces accurate results for a wider
range of inputs.

AudioProcessorParameterWithID pre-dates HostedAudioProcessorParameter,
which is why AudioProcessorParameterWithID was initially used for this
purpose.

Reintegrates changes from cf9fc84669

Previously, the top-level modal dismiss broadcaster would attempt to
dismiss all modals when the native file chooser was brought to the front
or clicked. This would end up calling Component::inputAttemptWhenModal,
which would bring the FileChooser's Component to the front, interrupting
the mouse click.

The fix is to avoid bringing the plugin window to the front when the
FileChooser is in a modal state. As the chooser is a native window, the
system should take care of enforcing the expected modal behaviour.

It's not clear why this issue only affects Cantabile. It seems that in
Cantabile, events from the native FileChooser get sent to the plugin
editor's parent HWND, whereas this doesn't happen in other hosts.
Perhaps Cantabile is hooking/intercepting window messages in some way.

This fixes a regression introduced in
a400d3ebe0.

float comparison

One issue affected the situation where the provided bounds wouldn't
start at (0, 0). Such bounds are regularly acquired by calling
Rectangle::reduced().

The other issue affected the width calculation of fractional items.
The error wasn't correctly integrated during the computation, and as a
consequence the last fractional element would exhibit all the
accumulated error.

Previously, the following sequence of events was possible:

Background thread                   Main thread
------------------------------------------------------------------------
Lock::tryAcquire()
    Run to blockingMessage->post()

                                    BlockingMessage::messageCallback()
                                        Run to abortWait.set (1)

Lock::tryAcquire()
    Exit through return true

Lock::~Lock()
    Destroy memory used for Lock

                                    BlockingMessage::messageCallback()
                                        Execute lockedEvent.signal()
                                        Memory already freed, crash