Some plugins (e.g. FabFilter Pro-C 2) will reopen their windows at their
previous size, but without accounting for a new scale factor. For these
plugins, we need to explicitly set a scale factor of 1 before calling
getSize for the first time, in order to ensure that the plugin knows it
should return its desired unscaled size, and not its size at the scale
factor it was using last.

Other plugins (Surge) misreport their desired size when it is requested
before the window has become visible. For these plugins, we need to
re-request the plugin's desired window size after it has opened.

The problems above are mostly noticeable when opening/reopening plugins
on a hi-DPI display on Windows.

This fixes some issues with Izotope Ozone 9:
- Resizing would stutter, and could leave the view in an inconsistent
  state.
- Closing and reopening the view after resizing would display black bars
  around the editor view.

The root of the problem was that the call to Component::setSize() inside
the resizeView call checked whether the plugin supported resizing. If
not, it would force the embedded view back to the current size. This
behaviour is incorrect - if the plugin requests a resize via resizeView,
the new size should be applied whether or not the plugin "supports
resizing".

This fixes a bug on Windows where plugins that do not implement the
IPlugViewContentScaleSupport interface opened in the AudioPluginHost
with their editors in the very top left corner of the window, rather
than below the window's titlebar.

Examples of plugins with no scaling support, suitable for reproducing
the issue:
- U-He Hive 2.1.1 Rev 12092 x64
- FabFilter Pro-C 1.23 x64

The scaling machinery in the component peer was causing problems for
hosted plugin views. Scaling the plugin view size requires close
collaboration between the plugin and the host, and it's important for
the host to have exact control over the size of the plugin's view. The
removed code in the HWNDComponentPeer was modifying the sizes of
embedded plugin windows, which would often leave them at an incorrect
size.

The faulty behaviour was especially noticable with plugins that do not
support DPI-aware behaviour. I tested with the following plugins (VST2 +
VST3), which should all now display correctly in the AudioPluginHost,
and assume the correct size when opened on hi-res displays, or dragged
between displays with different scale factors:
- Plogue AlterEgo
- U-He Hive 2
- FabFilter Pro-C
- Native Instruments Supercharger
- Surge

This commit removes the various compiler-specific JUCE_DEPRECATED macros and replaces them with C++14's deprecated attribute. It also removes the JUCE_CATCH_DEPRECATED_CODE_MISUSE flag as we can rely on the override specifier catching usage of these old virtual methods, and tidies up the DOXYGEN preprocessor checks as they were inconsistent across the codebase.

Previously, BadMatch errors were seen when there were several modal
windows, each with a native titlebar. Moving a window would attempt to
restack the windows, which was not possible because the JUCE windows
were not siblings. We actually need to restack the top level windows,
i.e. the windows containing the server-side decorations.

Negative indices should count backwards from the last explicit
row/column number. If the resulting line number would appear before
the first explicit row/column, implicit grid lines should be added
before the first explicit row/column.

Previously, the following series of steps would leave the window at
full-size on Windows:

- Open a JUCE Window
- Maximise it
- Minimise it
- Click the maximise button

The expected behaviour is that the window should return to its initial
size and position, but instead the window still fills the screen.

This issue wasn't present on Ubuntu/Unity because minimising does not
invoke ComponentPeer::handleMovedOrResized on that platform. It was not
present on macOS because the system is responsible for restoring the
previous window size on that platform.