Further improvements to reflectionzeug

Here is a list of things that currently bother me about reflectionzeug's implementation:
### the complicated property class hierarchy

**now and then:** the hierarchy emerged so that different types of properties could have different interfaces way back when the `Variant` class and options didn't exist. now, it still exists to provide the serialization implementations (`toString()`, `fromString()`) for different types and also to provide unification interfaces for integral types etc.
**problems:** it's too complex and you have to implement a `toString()` and `fromString()` method for every new type you want to store / access in a property. however, providing a those simple serialization methods is not sufficient for a variety of types, e.g., for integral types there different ways to represent them (academic, i.e., with mantissa and exponent, simple) and for floating point types you also need to specify the precision. you could also prefer to represent color value as simple floating point arrays in you gui rather in hex values. the floating point editor already circumvents `toString()` and `fromString()` for this reason.
**possible solution:** remove the serialization methods from properties so that any value type can be stores in properties "as-is". move and implement specialized serialization methods into the serializer / deserializer and editors. you would only have to specialize the property template if you want to support a special interface.
### the visitor pattern implementation

**now:** a "super-charged" visitor pattern implementation is currently used to determine the actual type of a property. it enables you to add new types to the visitor as a user of the library and is therefore relying on RTTI.
**problems:** the visitor implementation needs to perform at least one dynamic_cast per property. there is no way to determine the type of a property in a switch/case way without interrupting the instruction flow through the indirection of visit methods.
**solution:** replace it with some count of type system based on an integer value like in `QVariant`. But I have no exact idea yet how to do it.
### there are too many ways to do the same thing

**problem:** I have heard that someone found that there were to many ways to do the same thing. I am not sure what that means. _(needs confirmation)_
### the "owns property" flag of `PropertyGroup`s

**now:** Properties can be part of multiple `PropertyGroup`s. However, only one of them owns them, even though by default a group owns all of its children. To make it work, you have to set the "owns property" flag on every group but one to false.
**problem:** this is error-prone.
**solution:** store properties in groups within `shared_ptr`s.

---

I would like to invite everyone to comment on this and maybe add additional annoyances.