Don't return on error

[foodprocessor]

Describe your changes in brief

Returning an error from settingsReceived() stops the UI from functioning normally, so settingsReceived() should only return an error when it can't return a valid SettingsResponse.

This PR also includes some refactoring:

• broke settingsReceived() into multiple functions to improve readability
• on Windows, verify unmount is complete before moving on
• check validity of JSON before returning settingsResponse
• comment out call to processActiveSettings, which does nothing but cause the occasional error. We'll use it properly soon.
• removed our code from the Engine superclass (in helpers), into our inheriting class.
• Use m_ prefix for class member fields.
• Improved Windows build script (faster iteration time)

What type of Pull Request is this? (check all applicable)

• Refactor
• Feature
• Bug Fix
• Optimization
• Documentation Update

Checklist

• Tested locally
• Added new dependencies
• Updated documentation
• Added tests

Related Issues

• Related Issue #
• Closes #

[foodprocessor]

Now that errors are only returned in truly exceptional cases, settingsResponse is returned to the VMS basically every time that settingsReceived is called. That means we are sending an updated JSON schema to update the plugin settings UI every time we are called. That's good because it means we can update what the user sees on the plugin settings page. But it turns out our JSON is not always valid, and when it isn't, it crashes the whole server.
So I'm going to add a JSON validation step to settingsReceived to (hopefully) prevent ever returning malformed JSON to the VMS.

[foodprocessor]

Ok, all issues seem to be settled.
It took a lot of time to find out the hard way that fs::exists can throw an exception!