WIP: Adapt controls to Hi-DPI

[0tkl]

I expect this PR will eventually be composed with these commits:

• Corrections
  • Corrections to some of sizer->Add(...) where a positive border width was specified, but the border direction was not specified;
  • Corrections to some of sizer->Add(...) where the border direction was specified, but the border width is set to 0;
  • Corrections to a sizer->Add(...) where both Center and Expand were used;
  • Corrections to a misuse of sizer->Add(...);
• wxSizerFlags().Border() for implicit Hi-DPI management
  • Rewrite all usages of 5px/10px/15px borders in sizer->Add() with wxSizerFlags().Border() family
  • Rewrite all usages of 6px/12px borders
  • (Undecided) Rewrite all usages of 3px borders
• (Cosmetic, optional) Rewrite all cases where the border width is 0 with wxSizerFlags()
• FromDIP for Hi-DPI support
  • Replace all wxSize(-1, -1) with wxDefaultSize
  • Wrap all constant wxSize(a, b) and SetSize(a, b) with FromDIP
  • Wrap all the column width with FromDIP, in all Create/Append/Insert columns
  • Simple custom-drawn controls (not involving triangles), such as the subtitle grid
  • Hard custom-drawn controls such as the video slider and audio display
  • A overhaul to the color picker. The current code relies on a one-to-one correspondence between 256 pixels and color values

[arch1t3cht]

I haven't looked at the code yet, but one note upfront:

wxWidgets generally advises against using FromDIP in their docs and instead recommends using text measurements instead:

Actually, using any pixel values is not recommended and replacing them with the values based on the text metrics, i.e. obtained using wxWindow::GetTextExtent(), or expressing them in dialog units (see wxWindow::ConvertDialogToPixels()) is preferable.

Of course FromDIP is not forbidden and is fine to use for e.g. Aegisub's initial window size, but if a size can be reasonably computed using text extents (like column widths in a table) that is strongly preferred.