Tiny edits in attempt to fix final site markdown display problem (#1016)

* Fixing markdown problem(?) in quick-menu.md

I noticed the final page https://docs.libretro.com/guides/quick-menu/ was showing the correct markdown for the controls bullet list, even though the github.com page shows the final markdown results correctly (in Preview and while viewing the page before editing).  I'm thinking this line break might fix it.

If it does fix it, we probably need similar fixes elsewhere.

Regardless of whether this line break fixes it, it seems there's a markdown engine/versioning difference between (for example) github and docs.libretro.com.

* Fixed "!!!" Hint bubble code

I coded a hint bubble wrong.  I had carefully modelled other code, but still made a mistake.

* Markdown sub-bullet level fix(?)

Sub-bullets that display AOK on github.com site are not correctly levelled on the final docs.libretro.com site.  On docs.libretro.com the sub-bullets show as main-bullets with no sub-levelling.  There must be a markdown breakage/versioning/problem on docs.libretro.com.

I'm hoping the extra indentation in this new commit will fix it regardless.  I added two _extra_ spaces to "-" sub-bullets even when they were already correctly spaced.

docs/guides/quick-menu.md

@@ -6,6 +6,7 @@ The **Quick Menu** is effectively RetroArch's pause menu.
 The Quick Menu can be accessed by pressing a certain gamepad combination, pressing the `F1` key on your keyboard, or tapping on the "[Invader](../start/understanding/#logomascot)" or "Menu" button on most Gamepad Overlays.
 
 The RetroPad button combination for opening the Quick Menu can be changed at `Settings>Input> Hotkeys> Menu Toggle`. Users select the combination from a list (Custom combinations cannot the applied):
+
 * None
 * Done + Y + L1 + R1
 * L3 + R3
@@ -27,4 +28,4 @@ The Quick Menu provides access to many core-specific settings and options while
 The most important function exclusive to the Quick Menu (aside from `Resume Content`) is `Close Content`. This safely 'shuts off' the emulated system and its content, returning the user to RetroArch's main menu without having to quit RetroArch completely.
 
 ### Disc Control
-Another "exclusive" function that appears with certain cores is swapping discs using the `Disc Control` option: See [Disc Swapping](./disc-swapping).
+Another "exclusive" function that appears with certain cores is swapping discs using the `Disc Control` option: See [Disc Swapping](./disc-swapping).

docs/guides/roms-playlists-thumbnails.md

@@ -65,7 +65,7 @@ All menu drivers can display fullscreen thumbnails when pressing Start, and Y bu
 Thumbnails can be retrieved in multiple ways:
 
 * **Playlist thumbnail downloader (recommended)**: under Online Updater menu, all available thumbnails can be downloaded for a playlist. RetroArch will connect to http://thumbnails.libretro.com and retrieve the available thumbnail.
-  - _WARNING_: the Playlist Thumbnails Updater process will over-write [custom thumbnails](#custom-thumbnails) set by the user for any game that has an associated thumbnail on the server.
+    - _WARNING_: the Playlist Thumbnails Updater process will over-write [custom thumbnails](#custom-thumbnails) set by the user for any game that has an associated thumbnail on the server.
 * **Individual thumbnail downloader**: there is a Download Thumbnails option for each entry in playlists. For RetroArch version 1.17.0 or later, you may hit download up to 3 times to try the flexible matches.
 * **On-demand thumbnail downloader**: if the respective option is enabled, RetroArch will try to download each thumbnail as the playlist is browsed. For RetroArch versions 1.17.0 or later, you may try flicking back and forth between entries up to 3 times to try the flexible matches. By default, on-demand thumbnail downloader does not try to fetch thumbnails based on ROM name, enable Settings / Playlist / Use filenames for thumbnail matching options for that.
 
@@ -176,7 +176,7 @@ Since playlists are managed in text-only JSON format, there are a few third-part
 ## Custom thumbnails
 Users can set a custom thumbnail (i.e. a thumbnail that is different from the one automatically provided by RetroArch) by following the process below.
 
-!!! Terminology Note: "Game Name"
+!!! Hint "Terminology Note: Game Name"
     The term _Game Name_ refers to the name displayed [within a playlist in RetroArch](#retroarch-playlist-scanner), _not_ to the filename of the underlying file on the computer or device.  _Game Name_ in this document is synonymous with playlist item label, playlist entry, content name, game title.
 
 - __File & Filename__. Name a PNG image file with a base filename that matches a game title displayed in a playlist.  _Example_: if the game name is `Q-Bert's Qubes (USA)`, the intended image file must be named `Q-Bert's Qubes (USA).png` _(See below for additional flexible name matching options.)_
@@ -186,8 +186,8 @@ Users can set a custom thumbnail (i.e. a thumbnail that is different from the on
 
 **Flexible name matching.** RetroArch versions 1.17.0 or later will attempt up to 3 different match techniques to associate a playlist item with a [properly located](#thumbnail-folder-paths) local thumbnail image file, in the following order:
 
-1. __ROM file name <-> .png file name match__. A ROM file `Q-Bert's Qubes (USA) (1983).a26` would receive the thumbnail `Q-Bert's Qubes (USA) (1983).png` if it exists, regardless of how the game name appears in the RetroArch interface.
-2. __Game name <-> .png file name match__. `Q*Bert's Qubes (USA)` in a playlist would receive the thumbnail `Q_Bert's Qubes (USA).png` if it exists. `*` is an invalid character and must be replaced with `_` in the image filename.
+1. __ROM file name <-> .png file name match__. A ROM file `Q-Bert's Qubes (USA) (1983).a26` would receive the local thumbnail `Q-Bert's Qubes (USA) (1983).png` if it exists, regardless of how the game name appears in the RetroArch interface.
+2. __Game name <-> .png file name match__. `Q*Bert's Qubes (USA)` in a playlist would receive the local thumbnail `Q_Bert's Qubes (USA).png` if it exists. `*` is an invalid character and must be replaced with `_` in the image filename.
 3. __Short game name <-> .png file name match__. RetroArch looks for a local thumbnail named after a shortened form of the game name ignoring all text starting at the first round bracket, in other words ignoring informational tags like Region etc. `Q-Bert's Qubes (USA) (1983) (Parker Brothers) [h]` in a playlist would receive `Q-Bert's Qubes.png` if that local image file exists.
 
 ### Thumbnail folder paths
@@ -232,28 +232,27 @@ follow the steps below.
 
 ### Detailed Steps
 
-- __Fork the repository.__ Visit the github.com [libretro thumbnail repository](https://github.com/libretro-thumbnails/libretro-thumbnails) directory that you want to contribute to and click the fork button.  You must fork it at the level of specific console. The Fork button won't appear if you're viewing a lower level folder in the respository like "boxart" or "snaps.”
-  - _Example_. If you are doing GBA thumbnail work you should fork 
+- __Fork the repository.__ Visit the github.com [libretro thumbnail repository](https://github.com/libretro-thumbnails/libretro-thumbnails) directory that you want to contribute to and click the fork button.  You must fork it at the level of specific console. The Fork button won't appear if you're viewing a lower level folder in the respository like "boxart" or "snaps.” _Example_. If you are doing GBA thumbnail work you should fork 
 [Nintendo_-_Game_Boy_Advance](https://github.com/libretro-thumbnails/Nintendo_-_Game_Boy_Advance/).
-  - **Why "Fork" your own**?  Every part RetroArch's code and materials are open and accessible on github for input from any public volunteer (via Pull Request), but only official admins have direct edit access.  Forking means copying your own copy of the project to freely draft changes in your own separate work area.  Later you’ll send your proposed changes to the official project.
-  - _Warning_: You must visit and fork the _current_ github project for the libretro thumbnail repository, for example [this one for SNES](https://github.com/libretro-thumbnails/Nintendo_-_Super_Nintendo_Entertainment_System), not to be confused with the similar-looking [archived version](https://github.com/libretro/libretro-thumbnails) which is inactive.
-    - Correct: https://github.com/libretro-thumbnails/
-    - Incorrect:  https://github.com/libretro/libretro-thumbnails
+    - **Why "Fork" your own**?  Every part RetroArch's code and materials are open and accessible on github for input from any public volunteer (via Pull Request), but only official admins have direct edit access.  Forking means copying your own copy of the project to freely draft changes in your own separate work area.  Later you’ll send your proposed changes to the official project.
+    - _Warning_: You must visit and fork the _current_ github project for the libretro thumbnail repository, for example [this one for SNES](https://github.com/libretro-thumbnails/Nintendo_-_Super_Nintendo_Entertainment_System), not to be confused with the similar-looking [archived version](https://github.com/libretro/libretro-thumbnails) which is inactive.
+      - Correct: https://github.com/libretro-thumbnails/
+      - Incorrect:  https://github.com/libretro/libretro-thumbnails
 - __Add / Upload your new image file.__ When viewing a specific thumbnail type folder (e.g. Named_boxarts, Named_titles, Named_snaps) within *your fork* of the thumbnails repository, click the pulldown button (near top right) that says **Add file** to see 2 options:
-  - +Create new File
-  - Upload File.
+    - +Create new File
+    - Upload File.
 - __Choose "Upload File"__.  Select your new chosen image file.  In this stage you are uploading to your fork/branch of the project.
-- __Follow all guidelines for a proper contribution.__
-  - Your choice of image file should meet the libretro thumbnail [rules in the ReadMe](https://github.com/libretro-thumbnails/libretro-thumbnails/blob/master/README.md), e.g. width scaled down to 512px.
-  - For snaps (in-game screenshots), choose a good clear artful image that shows the art, spirit, or action of the game in normal or ideal gameplay. For examples of well-chosen well-composed in-game screenshots, see the back-of-box images printed on officially published games.
-  - Name your image file correctly.
-    - If replacing an existing image, name your new image file exactly as the previous one to guarantee that it will be matched to the relevant game name in RetroArch. (Unless your contribution is to correct an erroneous filename that doesn't match the game name database.)
-    - If uploading a new thumbnail that has no prior existing version, research the naming conventions of libretro and how the game is named in databases. Name the image file according to the game name that RetroArch assigns in the playlist.
-  - Use the correct path.  Choose the correct console system folder and thumbnail type folder in the repository.
+  - __Follow all guidelines for a proper contribution.__
+    - Your choice of image file should meet the libretro thumbnail [rules in the ReadMe](https://github.com/libretro-thumbnails/libretro-thumbnails/blob/master/README.md), e.g. width scaled down to 512px.
+    - For snaps (in-game screenshots), choose a good clear artful image that shows the art, spirit, or action of the game in normal or ideal gameplay. For examples of well-chosen well-composed in-game screenshots, see the back-of-box images printed on officially published games.
+    - Name your image file correctly.
+      - If replacing an existing image, name your new image file exactly as the previous one to guarantee that it will be matched to the relevant game name in RetroArch. (Unless your contribution is to correct an erroneous filename that doesn't match the game name database.)
+      - If uploading a new thumbnail that has no prior existing version, research the naming conventions of libretro and how the game is named in databases. Name the image file according to the game name that RetroArch assigns in the playlist.
+    - Use the correct path.  Choose the correct console system folder and thumbnail type folder in the repository.
 - __Commit.__ The "Commit" button will save your change to your copy of the repository. You should generally commit to your own _master_. 
 - __Pull Request (PR)__.  Look for the button or option for a Pull Request when you Commit, though you may wait until you have finalized multiple changes (commits) and then include them all in a single PR. A Pull Request means sending a request to the official members to take your contribution (i.e. merge your fork) into the RetroArch repository.  Admins will review your proposed changes and decide whether to accept it.  You will eventually see a confirmation that it was approved or a discussion message if changes are needed.  It may take time (even weeks or months) before an admin is able to examine the request, so please be patient.
 - __Verify that your Pull Request is active and correct.__ For example, if you made a Pull Request to contribute a Gameboy thumbnail then you can [view the request publicly listed at the official repository](https://github.com/libretro-thumbnails/Nintendo_-_Game_Boy/pulls).
-  - _Warning_: It is possible to accidentally send a Pull Request to yourself if you committed your changes to your sub-branch instead of your own _master_. If needed, approve your PR to yourself to merge your sub-branch changes to your master, then do a Pull Request from your master to the official Libretro master project. For clarity on github.com, you can hover on any abbreviated branch path label to see a pop-up of the full path label. 
+    - _Warning_: It is possible to accidentally send a Pull Request to yourself if you committed your changes to your sub-branch instead of your own _master_. If needed, approve your PR to yourself to merge your sub-branch changes to your master, then do a Pull Request from your master to the official Libretro master project. For clarity on github.com, you can hover on any abbreviated branch path label to see a pop-up of the full path label. 
 
 __About "Syncing."__ Contribution work involves changing your copy of the project while other people may be changing the official repository _after_ you created your fork.  Github provides options to keep both your copy ("downstream") and the official repository ("upstream") up-to-date with ongoing changes.  If you make multiple changes within your fork, you can use the **Contribute button** > Open Pull Request to send all your changes as one PR.  You can use the __Sync button__ button to update your fork with other people’s changes that have happened upstream.