Ensure that plugin entry points are always exported on macOS and Linux (otherwise, plugins won't load in macOS release builds)

The Makefile of the JuliaProcessor plugin used
absolute file paths, which prevented compilation.
I have replaced the absolute path with a shell
macro as suggested by Julia's embedding
documentation.

Fixing this revealed a second problem: the linker
flags were incorrect. I have replaced the
offedning flag '-ljulia' with build flags
generated by julia, as per Julia's embedding docs.

See issue #80

* Added possibility to auto-save/load parameters for each created
  plugin.
* Some fixes needed for LookAndFeel code generation.
* Fixed plugin type wasn't loaded correctly into PluginGenerator after
  restarting.
* Fixed boolean parameters stored incorrect values inside.
* Fixed some bugs with parameters.

* Changed the order of plugin types at the enum definition.
* Changed some plugin definition names to be more user friendly and to
  be consistent with OE GUI.
* Removed "DataThread" plugin type from the "Plugin type" comboBox at
  the plugin creation page. Now to create DataThread plugin user
  should select "Processor" plugin type, then "Source" processor type
  and click "Use separate thread" button
* Removed possibility to create "Utility" processors plugins since we
  don't want to let users create such types of plugins.
* Removed possibility to generate editor and content component files
  for non-processor plugins since this feature was redundant.
* Removed "Plugin" page from "Config" for non-processor plugins since
  they have no built-in parameters.
* Added missing LookAndFeel related files to stage.
* Refactoring.

* Fixed OE_GUI_MoonShard template;
* Added possibilty to create Source plugins either using
  DataThread or Processor classes in more convenient way
  (as discussed with Josh before);
* Fixed code template for FileSource plugins;
* Fixed minor bug related with TiledButtonGroupManager class;
* Now the plugin's folder is selected by default when creating new
  plugins.
* Some minor refactoring.

* Added feature to create plugins using VisualizerEditors;
* It's possible to manipulate with GUI content both of GenericEditor's
  plugin component and Visualizer canvas (in the tab or window);
* Created file templates for VisualizerEditor and Visualizer (Canvas);
* VisualizerEditor class minor improvements;
* Other minor improvements;
* Refactoring and stylystic fixes.

* Fixed OpenEphysLib files;
* RHD2000Thread class some refactoring and stylystic fixes.

* Created 3rd slider-page on creating project steps which is used
  to select appropriate plugin, processor type, plugin GUI template,
  other options.
* Created plugin GUI templates system;
* Created some plugin GUI templates for GenericEditor;
* ButtonGroupManager and TiledButtonGroupManager classes minor
  improvements and fixes;
* Changed index of ProcessorType::UtilityProcessor;
* Other minor bugs fixes.

* Added template for creating appropriate JUCE GUI component which will
  be automatically created inside plugin editor.
* Some improvements to the editor plugin template due to the addition
  of GUI component inside it.
* Added possibility to change desired with of the plugin in the config.
* Some minor improvements.
* Some stylystic fixes.

It was in the private section. Still is practically...
Motivation:
Whenever an editor is closed, it destroy it's DataViewport tab (if it exists)
I don't want my "shared" tab to be closed when any one editor is closed, and I can fool the
VisualizerEditor destructor now.

Implemented @sept-en's tip.
VisualizerEditor implements the listener class, with a dummy windowClosed() method.
Derivations of VisualizerEditor can optionally implement windowClosed().

This might be very Cyclops Stimulator specific addition, and there might be a better way to do this:
DataWindow is used only by VisulaizerEditors. So I added a callback to the editor whenever an (open) DataWindow is closed.
I don't know how useful this might be for plugins other than for Cyclops.

Motivation: Since the datawindow is also shared by CyclopsEditors, when a window is closed, only the editor which created the window would get it's windowSelector button toggled back to "off".

With this PR, the button toggles, and the editor's windowClosed callback is called, in which the message is passed to peers through an internally maintained structure -- so that they can toggle their buttons too.

* Added ParametersEditor;
* Some improvements of Parameter class;
* Added possibility to generate code for parameters;
* Added possibility to save/load parameter in the project file.
* Other major and minor improvements.

These changes were made to primarily to accommodate for the cyclops-stimulator. Since buttonClicked manipulates the DataViewport via AccessClass, a sub-class of VisualizerEditor cannot functionally override the method.
Hence:

* Added protected methods which manipulate DataViewport (via AccessClass)
* moved the SelectorButtons into protected area, essential!
* All of the additions are essential to the cyclops-stimulator.
* There is NO change in the public interface.

Now, my buttonClicked method can access the SelectorButtons, manipulate (anything about!!) DataViewport.
Please remove the (new) comments from VisualizerEditor::buttonClicked (.cpp), they are not needed anymore.

* Added docs for the class. Override only buttonEvent (as for other non-visual editors)
* Started fixing other editors, a lot of redundant code can be removed.
* See comments in VisualEditor.cpp

Refactoring.