Adapt Plugin

Alec has this page in his docujmentation. Will it remain?

Add necessary plugin path changes for 1.16

Add Icon SVG Changes

Adapting plugins to the installer

In order to work with the installer plugins needs to be modified. The changes includes some general updates & cleanup:

Updating to the latest plugin API v 1.16 (as of 5.0.0).
Using the new function GetPluginDataDir instead of previous GetpSharedDataLocation(). This is so that the plugin can find it’s own data directory even if relocated to a new location.
Ensure that LD_LIBRARY_PATH is not overwritten by plugin if it’s already set (for plugins which uses it, most don’t)
Use the new find_in_path() function to locate binary helpers as a fallback if hardcoded paths does not work (for plugins which uses helpers, most don’t).
Ensure that plugin does not link to libraries outside the git tree, in particular the msvc opencpn.lib import library.
Ensure that plugin is installed in sane paths, in particular on Mac.

And some new code:

Build a .tar.gz bundle together with the tradtional installer.
Add support for building a plugin metadata XML file.
Give the package a more unique name. This is a requirement from deployment sites like bintray where all plugins share a common namespace.
Add continous integration support (if not already in place).
Add support for building a flatpak plugin.

This list is supposed to be exhaustive — many plugins are simple enough.

There are two examples on the this process

[oesenc_pi](https://github.com/bdbcat/oesenc_pi/). This is as complicated as it gets with binary helpers, extra libs and data.
[ShipDriver_pi](https://github.com/Rasbats/shipdriver_pi) is simpler example, but still complex enough to cover most plugin cases. The repo contains a branch called patches which a clean , rewritten history how the adaptation is done.

Testing a new or modified plugin

The item to test is a tarball. The easiest way to test it is to use the new "Import plugin" function which allows using a plugin directly without downloading it from an url.

More complete testing requires the plugin to be available in a catalog. See the plugins project at https://github.com/opencpn/plugins

Source code formatting

The preferred style for cmake files is the modern one with lower_case commands, two spaces indentation and plain endif (), something like

if (MSVC)
  set(_msvc_flag "some value")
endif ()

This is supported by the cmake-format utility, https://github.com/cheshirekow/cmake_format. A .cmake-format options file to use is part of the [ShipDriver_pi](https://github.com/Rasbats/shipdriver_pi) plugin. cmake-format has also been used with the same settings in the main opencpn project where it has been used to format several thousand of lines with good results.