Generate bindings + typings for non-typedef'd template parameters

[donalffons]

Many template specializations are currently not typedef'd by OpenCascade, e.g. Handle<IMeshTools_Context>. Therefore, this type is effectively not usable.

When the usage of such a type is encountered, the following message is written to the logs during typescript generation (the logs contain 21.500 of those messages):

could not generate proper types for type name 'opencascade::handle<Standard_DimensionMismatch>', using 'any' instead.

To fix that, it might be best to do the following:

1. In a first pass, make a list of all the template parameters used in all declarations
2. Filter the list and throw out all template parameters that are already typedef'd (for those, the build system will generate bindings automatically)
3. Add some simple C++ code, with typedef's for the remaining template parameters
4. Then run the build system as usual

[donalffons]

...additionally, it might make sense to introduce wrapper lambda functions for known template arguments, like those of type opencascade::handle which can convert from the underlying type to the typedef'd type implicitly. The binding code might look like this:

  class_<BRepMesh_IncrementalMesh, base<BRepMesh_DiscretRoot>>("BRepMesh_IncrementalMesh")
    // ...
    .class_function("Perform_2", 
      std::function<void(BRepMesh_IncrementalMesh &, const opencascade::handle<IMeshTools_Context> &, const Message_ProgressRange &)>([](BRepMesh_IncrementalMesh& that, const opencascade::handle<IMeshTools_Context> & theContext, const Message_ProgressRange & theRange) -> void {
        that.Perform(theContext, theRange);
      }
    ), allow_raw_pointers())
    // ...

This would have the additional benefit of simplifying the JS code, as creating the Handle_ type explicitly would no longer be required.

...as this would be another breaking API change, this might be a candidate for a 3.x version.