g++ 4.7 compile fix in vector11

With g++ 4.7, the following error occurs when trying to compile code that uses Vector11:

```
../OpenMesh/Core/Geometry/Vector11T.hh: In function ‘decltype ((_v1 % _v2)) OpenMesh::cross(const OpenMesh::VectorT<LScalar, DIM>&, const OpenMesh::VectorT<RScalar, DIM>&) [with LScalar = float; RScalar = float; int DIM = 3; decltype ((_v1 % _v2)) = OpenMesh::VectorT<float, 3>]’:
../OpenMesh/Core/Geometry/Vector11T.hh:89:19: error: ‘OpenMesh::VectorT<float, 3>::container OpenMesh::VectorT<float, 3>::values_’ is private
```

It looks like this version of g++ would not be able to deal with the decltype statement used when overriding the "%" operator, where the "this->values_" part is not working properly. This issue should be fixed with this merge request.

See merge request !87

Added unit test to trigger GCC alignment bug. See #32.

Merge this even if CI unit tests fail. Failed unit test expose a compiler bug.

See merge request !86

Propmgr

Added some more convenience to the PropertyManager class.

See merge request !85

Stl type check

implemented the suggested changes from #24 by checking stl files for the keyword solid instead of computing binary file size.
closes #24 

See merge request !83

Updated changelog for 6.3



See merge request !82

Fix undefined MSVC macro warning



See merge request !80

fix CirculatorT type-pun warning on GCC6

fixes #28

See merge request !78

(fixes #28)

changed incorrect class into struct



See merge request !77

document that DecimaterT::decimate does not perform garbage collection on the mesh

addressing #27 

See merge request !76

Hash functions



See merge request !75

Vs2015 update3



See merge request !74

Split openmeshcore static/shared MinGW compilation

As with ms compilers, the shared/static compilation depends on export macros.

Besides this is inconsistent with the behavior for openmeshtools library.

Why did you add this ?

See merge request !72

As with ms compilers, the shared/static compilation depends on export macros.
Anyway this is inconsistent with the behavior for openmeshtools library.

Why did you add this ?

- Based on the macro provide partial specializations for std::hash<>
- for vertex,halfede,edge, and face handles.
- Add a free function hash_value(BaseHandle) for boost::unordered_set/map