Plugin system needs to be redone - please provide suggestions what changes should be made in the DevKit for OCTproZ v2

[spectralcode]

OCTproZ makes use of the low-level API for extending Qt applications. However, the Qt plugin API is not used correctly in OCTproZ:

• the different plugin interfaces/classes that are defined in the DevKit should only have pure virtual functions
• the plugin classes defined in the DevKit should not inherent from QObject
• it is not necessary to use an enum in the Plugin class to detect if the plugin is an AcquisitionSystem or an Extension. This should be done with qobject_cast but is currently not possible; probably due to the two bullet points mentioned above

Qt provides example code on how to use the plugin API correctly: https://doc.qt.io/qt-5/qtwidgets-tools-plugandpaint-app-example.html and: https://doc.qt.io/qt-5/qtwidgets-tools-plugandpaint-plugins-extrafilters-example.html

These are major changes that will affect the compatibility of OCTproZ plugins created with the current version of the DevKit. Since OCTproZ uses semantic versioning, the version number must be changed to 2.

To avoid having to change the major version of OCTproZ again in the near future, please let me know what other changes or features you suggest for the DevKit. I think it's better to include all desired features at once and then not change the DevKit for as long as possible.

Other features to add:

• Plugins should be able to draw into B-scan and en face view outputs
• Fix linux bug where QFileDialog is not usable with plugins when a GL window is open in OCTproZ --> Add "dialogAboutToOpen" and "dialogClosed" signals to plugin class.
• Add startRecordingRequest() signal to plugin.h
• Fix typo in acquisitionsystem.h: "acqusitionRunning"

Maybe to add:

• A way to let one extension talk to another extension
• Maybe it would be useful if plugins could instruct OCTproZ to start recording (add startRecordingRequest() signal to plugins.h)
• Consider using componentsystem

[spectralcode]

Some more ideas to evaluate:

• Use a robust thread safe producer/consumer design pattern for data acquisition (acquisition thread) and GPU processing (processing thread). Possible approaches that need to be compared to ensure max speed for MHz OCT: o AcquisitionBuffer with QMutex in getter and setter methods for bufferReady flags o Using a lock-free queue (something like: https://github.com/cameron314/readerwriterqueue )
• In some cases, AcquisitionSystem needs to be informed if recorders are initialized before data acquisition is started. Maybe add a slot in AcquisitionSystem and a corresponding signal that is emitted in init and uninit method of rawRecorder and processedRecorder