Add support for API 3

[jaybz]

I'm not sure if this is how you intended to handle this but I've set things up such that OnSettingsEventHandler() fires immediately after OnConnectEventHandler() when settings are available along with the info payload. This makes sure that plugins will be able to handle settings changes from the same handler regardless of whether the settings came from the info or settings payload from Touch Portal. In any case, here is PR for your review.

One thing I am considering changing is how the settings are passed onto OnSettingsEventHandler(). It's currently a List<Dictionary<string, dynamic>> as that is how the settings are passed by Touch Portal. I retained that for compatibility with the payload in case the way the data being sent changes but not the schema, but it makes more sense to combine everything into a single dictionary the way Touch Portal is currently sending the settings.

[oddbear]

OnSettingsEvent should only be fired if updated by TouchPortal or by Plugin, if I remember correctly. In many cases this is updated by the plugin on startup.

The info message should contain a Settings property and settings event is when updated.

Settings is stored in the registry. "Computer\HKEY_CURRENT_USER\SOFTWARE\JavaSoft\Prefs\app\core\utilities<pluginname>"

[jaybz]

I've added a few more commits to this PR as all of them are for the new API 3 additions and I've edited the title to reflect that.

[jaybz]

OnSettingsEvent should only be fired if updated by TouchPortal or by Plugin, if I remember correctly. In many cases this is updated by the plugin on startup.

The info message should contain a Settings property and settings event is when updated.

I don't see any reason why a plugin should have to handle the settings from info or the setting events separately other than to conform with how Touch Portal itself handles events exactly. I see more value in minimizing the amount of code required of the plugin particularly in an abstraction layer. That said, the difference is small. The question is, is it important to preserve Touch Portal's plugin lifecycle?

On that note, I implemented the hold event handler separately from the action handler, but the hold event handler can easily be rolled up into the action handler by adding a parameter or two with defaults for the regular press action. I'm just a little concerned of unintentionally changing the behavior of existing plugins as a result. Touch Portal will still fire the action event after the down and up events when an action is used on both the press and hold sections, but that does require explicitly declaring hold support in entry.tp.