Clean up utf8 parameter usage

[sbulen]

Fixes #6163
Closes #6494

The upgrader & installer already had mechanisms to set proper collation (utf8_general_ci), but they weren't working under certain circumstances. Tidying up this existing logic is cleaner than trying to implement partial utf8mb4 support. Utf8mb4 support should wait for #6409 .

Upgrader:
If $db_character_set were not utf8, and, you were upgrading into a DB with a utf8mb4 default charset/collation, you would get key too long errors as reported in #6163 . Note for this to happen you must not be utf8 already, and you must not migrate to a new Settings file (because doing so sets $db_character_set to utf8....).

This change prevents you from falling back to the DB default, which might use utf8mb4 (for new tables only, like qanda).

Installer:
utf8_support is now a function, no longer a variable, so any empty check was erroneous (function exists vs what the function returned...). Fixing them still yielded complex if statements that were trying to determine if we were using utf8.

But... we're using utf8 in 2.1... So the if statements could go.

The bottom line is that in 2.1, the installer and the upgrader should NEVER fall back to using the db-level default collation/charset.

[sbulen]

Testing completed. Installs & upgrades tested in mysql 8. Also did installs & upgrades in Windows as well as linux, under circumstances that produced the initial bug report. All OK.