Rely on OS-level tools for building the font cache

Nobody has claimed this yet.

The root issue of #10201 appears to be that in some OSX systems, /FontCollections is included in the font paths searched by the system, but not listed in the hardcoded paths in font_manager.py. While this could be fixed in a piecemeal fashion, I would like to propose instead to strictly rely on OS-level tools to list fonts instead.

This means:
- on Linux, `fc-list --format='%{file}\n'`
- on OSX, `system_profiler SPFontsDataType` (whose output can trivially be parsed by the stdlib plistlib module) (and fc-list too, if it is present).

On Linux, Xorg relies on fontconfig for font selection since at least X11R6.9 (2005; https://www.x.org/archive/X11R6.9.0/doc/html/fonts2.html#3 -- oldest doc on x.org). On OSX, system_profiler appears to be available since at least OSX 10.0 (2001; https://en.wikipedia.org/wiki/System_Information_(Mac)).

On Windows, we are already reading the fonts and font paths from the registry, which appears to be the "correct" place where the info is stored (https://msdn.microsoft.com/en-us/library/windows/desktop/dd144833(v=vs.85).aspx).

This means that on (rare) systems where fontconfig is not present, we'll only find the fonts shipped with Matplotlib (dejavu, etc.). To work around this, we can allow the user to run `python -mmatplotlib.font_manager recache --add-font-path foo --add-font-path bar`, with the expected effect (in fact there's already the (undocumented) `TTFPATH` and `AFMPATH` environment variables which have the same effect).

Thoughts?

Start with font_manager.py and inspect the current hardcoded font-path discovery. Compare the Linux fc-list and macOS system_profiler approaches described here, including plistlib parsing and optional fc-list use on macOS. Done means OS-level discovery covers the stated platforms while Windows registry handling remains intact.

Written by the indexing model from the issue text.