The NPObject contains following important methods: 
--------------------------------------------------

/**
 * Creates object for NP plugin npp of NPClass aClass. 
 */
NPObject* NPN_CreateObject(NPP npp, NPClass* class);

/**
 * Increases reference count for object
 */
NPObject* NPN_RetainObject(NPObject* object);

/**
 * Decreases reference count for object
 */
NPObject* NPN_RetainObject(NPObject* object);

/**
 * Calls object method
 */
... NPN_Invoke(...);
 
 
NOTE:
-----

 - In the plugin architecture, objects have two forms 
   - The NP 'wrapped' form of NPObject or e.g. CCPixNPSearcherObject
   - And the nonwrapped form e.g. CCPixNPSearcher or MCPixNPSearcher
 - Only the former form can be memory managed (Reference count set up and down) 
   - This means that if object wishes to maintain references to an NP object, 
     it needs to have access to the wrapped form. 
 - Wrapped form vs. Nonwrapped form
   - Wrapped form is more powerful, holding pointer also to the NP side handle
   - Nonwrapped form is easier for the programmer
   -> Still - to avoid refactoring - wrapped form should always be used 
 
Open questions: 
---------------

 - How to handle const safety with wrapper objects?

Nontrivial things: 
------------------
 
 - Should the /inc/idc/* interfaces contain refernces to NPVariants 
    - At least the example code contains
    - More difficult for the programmer 
 - Who should create NP wrapping around objects? Interface or implementation class?
   E.g. Should CCPixNPPlugin or CCPixNPPluginInterface wrap searcher into 
   CPixNPSearcherObject form
    - In CCPixNPPlugin case - it doesn't really matter. Ownership is given away in any 
      case and the reference counting functionality is not needed in either side. 
    - Generally the implementing class should hold responsibility
    - E.g. If CNPSearchDocument wishes to hold ownership to its fields it needs
      to be able to add references to the fields it creates. 
 - Observers