Internal Changes SimBOB 1.4.1 -> 1.4.2

- RCComponent is now derived from RCCastable:
This makes the handling of component easier since there are no more special lists for each component-type required. Instead they can simply be (tried to be) casted to the desired type - including to any other implemented interface-type

- the RTL-macros require the specification of the base class
Since the virtual function CastTo() (from RCCastable) is now used to cast components to their base type (e.g. RCControllerComponent) it is nesessary to call it for the baseclass as well. Thus, the macros had to be changes that they require a 2nd parameter!

- The referring component pointers are linked at realization rather than at creation:
This allows you to refer to components in the simulation file that are not created yet but will be later in the file, possibly resulting in cyclic dependencies - which is necessary in some cases (for the internal communicators for instance).

- added virtual function Clear() to RCComponent:
Due to the possible cyclic dependencies between components it is not sufficient to clear all links to other components in the destructor since the destructor will only be called when no more pointer to the specific component exists. Thus an extra-cleaning mechanism is required. In this function the components should call Clear() for all their component pointers and don't forget to call the baseclass' implementation of Clear()!

- new component (sub-)type: TRCSimDialogComponent
It is derived from TRCGlobalSimComponent AND from RCDockableDialog. It can be hidden/shown via the new popup-menu "Simulation Dialogs..." in the Menu "View".

- all global sim components have now support for threads.
Since sim dialogs often require an own thread to regularly update their data it was just reasonable to move the support for it to the base class. This also allowed me to simplify the implementation of RCRobot (derived from RCGlobalSimComponent).

- all global sim components have the ability to store data in the ini-file.
The main reason for this was to store the window states of the simulation dialogs but it could be used for any other data as well. To use it just overwrite the virtual function TransferIni().

- components can display more than just their shape:
Peripheries for example can display rays representing their singles or whatever suits. So far only the RCRangeSensor uses this ability to display the laser beam. In the menu "3D view" you can switch visual object type on/off. Initially only physical object are displayed.