Automatically convert v1 config files

[akenion]

This was initially part of #72, but also depends on #75, so this is being broken out as a standalone issue.

Per @ewodrich in #72:
Converting current users to new configuration

For this release we also need to convert existing wordfence-cli.ini files for current users to the new format that includes a [DEFAULT] global option, [MALWARE_SCAN] (formerly [SCAN]), and [VULN_SCAN] options.

After the user installs/upgrades to version 2.0.1, they will likely next run a wordfence cli command. When any command is input, the user should be prompted to update their configuration. The expected flow is:

• User updates wordfence CLI to latest version and has an existing wordfence-cli.ini file from prior to WF-CLI 2.0.1
• User runs any wordfence command,
• Prompt user with "A configuration file for an older version of Wordfence CLI was detected; would you like to update it now?" Y/n
• If n return user to command line. They will not be able to run wordfence CLI without having the new configuration in place.
• If "Y", prompt user to follow the prompts to update values and hit enter to keep existing values unless otherwise prompted. First showing the current option setting and then provide opportunity to change the current setting.

For example:

Current license: abcdefgdc4de91f7407da2c0ed4eafb1e160d91b4646d5a8f50f0b1901828d81
Would you like to automatically request a free Wordfence CLI license? [y/n] (default: n):n
Cache directory (current: ~/.cache/wordfence): [user defines or hits enter to skip]
Number of worker processes (8 CPUs available) (current: 4): [user defines or hits enter to skip]
Would you like to keep any custom settings? [Y/n] (default: Y)

Update the wordfence-cli.ini file with the new formats that includes:

• a global [DEFAULT] section with license key, cache setting, any other user defined settings that don't specifically apply to another option
• a [MALWARE_SCAN] section with number of workers and any other user defined settings that specifically apply to [MALWARE_SCAN]
• a [VULN_SCAN] section

[davidnuzik]

QA PASS

Tested with 1.1.0 binary and v2.0.1rc4 binary
Behavior is unchanged regardless of environment or installation method (based on prior exploratory testing with licensing and configs) so only tested with Ubuntu 22.04.3 and binaries here.

SUMMARY:
QA PASS - behaves as expected. Any prior 1.x config entry for [SCAN] gets migrated accordingly when update config when prompted with 2.0.1rc4 (more details on this in the NOTES section below). The tool behaves as I would expect after upgrading the config INI. The process is as Alex described in the issue summary (i.e. the prompts and process are as described).

DETAIL/FINDINGS:

For the flowing scenarios ensure upgrade works as expected and that malware-scan and vuln-scan work as expected:

• Test by installing 1.1.0 and configuring with free license, upgrade to 2.0.1rc4 by using the rc4 binary on the command line instead of the 1.1.0 binary. When prompted to update configuration answer yes but use the old/existing license key defined in the INI.
  --- Test again, but this time with 1.1.0 pick unique config settings such as a different cache directory (non-default) and a worker count of "3" for example. When update config ensure keeps these settings unless changed by user. Looks like the worker process count doesn't get detected, always defaults to '1' but this may be expected. I mentioned it to the team.
• Test as described above but overwrite old free license with new free license key automatically obtained from server.
• Test but with a premium license key with 1.1.0, then upgrade and use the old key. Still should work as expected.
• Test but when prompt to update config answering "n" for no works as expected (just gracefully exists 0 and takes you back to the command line)
• Test just like above, but now try to use the tool anyway without updating the config - try to run wordfence malware-scan . for example. This indeed does not allow the user to continue and still prompts to update config INI, as expected.
• Throughout all testing, ensure that during prompts, defaults (prior config settings) show and can opt to chose to keep them as they are or modify them and INI gets updated appropriately. (note the exception I mentioned in italics above regarding worker process count)

NOTES:
FYI: There was much more additional testing done w.r.t. licensing, upgrades, configuration/INI file, and various environments not described here during recent exploratory testing.

Here is an example of INI upgrade / migrate behavior when upgrade to 2.0.1rc4. The following assumes you are keeping your settings:
For example, config from 1.1.0:

[SCAN]
license = <license_here>
cache_directory = ~/.cache/wordfence
workers = 8

Becomes:

[DEFAULT]
license = <same_license_here>
cache_directory = ~/.cache/wordfence

[MALWARE_SCAN]
workers = 8

Once upgraded and configure by answering "y" for yes to prompt to update configuration file and manually picking '8' for worker processes again (default is '1' currently).

Therefore we can see that malware-scan specific settings get moved from [SCAN] section into the new [MALWARE_SCAN] section which replaces [SCAN]. Whereas the license key and cache directory are general settings and thus in a new [DEFAULT] section.