Fix UB from object slicing

[VorpalBlade]

This fixes the following undefined behaviour detected using Valgrind:

==28955== Thread 8 QThread:
==28955== Mismatched new/delete size value: 4
==28955==    at 0x4975979: operator delete(void*, unsigned long) (vg_replace_malloc.c:1181)
==28955==    by 0x40635AB: VcpThread::run() (vcpthread.cpp:610)
==28955==    by 0x612B4FA: QThreadPrivate::start(void*) (qthread_unix.cpp:466)
==28955==    by 0x69181B8: start_thread (pthread_create.c:454)
==28955==    by 0x699D043: clone (clone.S:100)
==28955==  Address 0x28979570 is 0 bytes inside a block of size 8 alloc'd
==28955==    at 0x4972093: operator new(unsigned long) (vg_replace_malloc.c:487)
==28955==    by 0x40564DB: FeatureBaseModel::setFeatureList(DDCA_Feature_List) (feature_base_model.cpp:364)
==28955==    by 0x409E2F8: MainWindow::loadMonitorFeatures(Monitor*) (mainwindow.cpp:1223)
==28955==    by 0x409DC2B: MainWindow::on_actionFeaturesScrollArea_triggered() (mainwindow.cpp:1163)
==28955==    by 0x4027193: MainWindow::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_mainwindow.cpp:239)
==28955==    by 0x402775C: MainWindow::qt_metacall(QMetaObject::Call, int, void**) (moc_mainwindow.cpp:304)
==28955==    by 0x5FA3B5C: void doActivate<false>(QObject*, int, void**) (qobject.cpp:4398)
==28955==    by 0x5A487AD: UnknownInlinedFun (qobjectdefs.h:320)
==28955==    by 0x5A487AD: UnknownInlinedFun (moc_qaction.cpp:374)
==28955==    by 0x5A487AD: QAction::activate(QAction::ActionEvent) (qaction.cpp:1106)
==28955==    by 0x4D02A2F: QMenuPrivate::activateCausedStack(QList<QPointer<QWidget> > const&, QAction*, QAction::ActionEvent, bool) (qmenu.cpp:1413)
==28955==    by 0x4D0545E: QMenuPrivate::activateAction(QAction*, QAction::ActionEvent, bool) (qmenu.cpp:1495)
==28955==    by 0x4B3AE5D: QWidget::event(QEvent*) (qwidget.cpp:9029)
==28955==    by 0x4ADB11E: QApplicationPrivate::notify_helper(QObject*, QEvent*) (qapplication.cpp:3276)

This happens when first switching to the "Features" view for a monitor. The cause is a heap allocated VcpGetRequest later being deallocated via a pointer to the base class VcpRequest. The fix is to ensure the base class has a virtual destructor. This also exposed that ~HaltRequest() etc had no actual implementations (causing a linker error). Mark the subclass destructors override with a default implementation.

While I discovered this as part of #74, it does unfortunately NOT fix that.

[rockowitz]

I've applied your changes to vcprequest.h in branch 7.0-dev, which is the current development branch. (git still pointed to 6.1-dev as the branch to which changes are applied. This also required iftesting out the destructor definitions in vcprequest.cpp.