This is accomplished by making the window and rendered framebuffer
sizes independent of one another. By separating the two concepts, we
can create rasterized graphics at higher (or lower) resolution than
what is shown on screen.

The window scale factor is used to scale the sizes of elements within
the window (and on Linux and Windows, the window size itself from the
requested logical sizes), and the px-per-unit scale factor dictates
the size of the rasterized render.

The default scaling factors are initialized by requesting the content
scale factor from GLFW (and dynamically responding to changes in the
content scale factor on platforms where GLFW provides support).

Testing is added on Linux where xvfb-run can be used to force a
HiDPI context.

- Clear the `scalefactor` and `px_per_unit` observables when the figure
  is closed. It's possible both may be used during a figure's lifetime,
  but that should not persist past a close.

- In the system scale factor callback, do not unconditionally resize
  the native window. Instead, leverage the fact that the observable
  callback will invoke a resize event, and that correctly will check that
  the root scene is not `nothing`.

- Do not completely ignore the scale factor on OSX. The difference is
  that there is a native scaling factor applied by the OS, but if/when
  the desired scale factor differs from the native scaling, we must
  still make adjustments.

Instead of polling for window size changes on every render tick, use
the size-changed callback from GLFW to only make changes when it is
known that there's been a change in the size of the window.

This solves a concurrency problem that can happen when the scale factor
is changed. The sequence of events looks like:

1. The `screen.scalefactor[]` value is changed
2. The listeners to `scalefactor` start to be notified.
3. Asynchronously, the `WindowAreaUpdater` listener attached to the
   `render_tick` observable runs.
4. The window area listener notices that the window size given the
   _new_ value of the scale factor doesn't match the scene size, so
   it updates the scene size.
5. The `scalefactor` listener responsible for resizing the window
   gets its slice of time to run, and it now sees that everything is
   already the "correct" size.

Therefore, the window is not resized, and instead the scene size is
rescaled in the opposite direction of the scale factor change.