Define abstract classes for the city object types

[liberostelios]

I propose this way for the definition of city object types. The idea is that we can introduce abstract types (denoted as _AbstractType) which define the basic properties of the objects and, then, there is a simple concrete type that include those properties and only adds the type property (e.g., see _AbstractBuilding and Building in 7b94613).

There are certain benefits:

• We avoid redundancy. In fact, all common attributes of city objects can be in a _AbstractCityObject, which all city objects extend. In addition, for complex types such as BuildingParts we can reuse parts from existing objects (e.g., see ab53416).
• We provide an easy way to extend existing objects through extensions (related to issue Attribute extensions #31). If someone wants to add properties to the Building without specifying a new type they can simply extend the Building object. If they want to make a new building type, though, they can extend the _AbstractBuilding and just add their own type property. In any case, they don't have to rewrite all properties of the original class.

As a caveat, though, we can't use the additionalProperties: false option with this mechanism (see why here), therefore we cannot force objects to only have the properties of the schema. There is a workaround, by listing again all "inherited" properties in the last class (explained at the end of this answer). Nevertheless, I believe it's better to just warn users about this through cjio validation, than really forcing them to follow the schema. After all, the whole point of JSON is to be more flexible.