Actually hide the subclass from wrapping code

Change-Id: Ia74ef5bed26f19fd286090e18fe81b768c56e592
Minor cleanups in vtkClientServerInterpreter

Change-Id: I7a7640e7ba0eef084fe3a0bfad599fe4131089b9
Add context to new instance and command functions

This allows other mechanisms than just C functions to be registered with
the ClientServerInterpreter. Particularly, it will allow for using the
Python wrappings if available rather than building CS wrappings as well.

The implementation would use std::function if supporting it from MSVC
2008 through more modern compilers were easier (MSVC doesn't use a tr1/
directory for TR1 includes and not all TR1 functionality is available as
std::tr1 (just std::)).

All command function calling is internalized as part of this since the
context is only known to the vtkClientServerInterpreter class. In
particular, the GetCommandFunction method is replaced with a
HasCommandFunction/CallCommandFunction method pair.

Change-Id: I827ccc42e69f676e48a8453123834d6dbbb535a5
Use Python wrappings to implement ClientServer wrappings

With the unified bindings option set, ParaView will use Python as the
backing implementation for ClientServer wrapping. The goal is to
minimize the size of the build for Catalyst and the CS wrapping code is
an obvious target.

ParaView's plugins have unified bindings forced off because they cause a
circular dependency which cannot be broken (the plugin library contains
the ClientServer wrappers which, with unified bindings, requires the
Python library which requires the main plugin library for the actual
work).

Change-Id: Ieeb115799147c44822831f9c569fa37c4146b891
Merge topic 'unified-bindings2' into next

99b9de8 Use Python wrappings to implement ClientServer wrappings
e9d58bc Add context to new instance and command functions
3255354 Minor cleanups in vtkClientServerInterpreter
f9f6482 Actually hide the subclass from wrapping code