usnic: fix proc structure memory leak

Valgrind showed this one, just a bit of sloppiness with the reference
counting.

Reviewed-by: Jeff Squyres <jsquyres@cisco.com>

cmr=v1.7.5:ticket=trac:4253

This commit was SVN r30832.

The following Trac tickets were found above:
  Ticket 4253 --> https://svn.open-mpi.org/trac/ompi/ticket/4253

ompi/mca/btl/usnic/btl_usnic_module.c

@@ -134,7 +134,7 @@ static int usnic_add_procs(struct mca_btl_base_module_t* base_module,
             continue;
         }
 
-        /* Add to array of all procs */
+        /* Add to array of all procs (proc_match gave us a reference) */
         opal_pointer_array_add(&module->all_procs, usnic_proc);
 
         opal_output_verbose(5, USNIC_OUT,
@@ -200,6 +200,7 @@ static int usnic_del_procs(struct mca_btl_base_module_t *base_module,
             for (index = 0; index < module->all_procs.size; ++index) {
                 if (opal_pointer_array_get_item(&module->all_procs, index) ==
                         proc) {
+                    OBJ_RELEASE(proc);
                     opal_pointer_array_set_item(&module->all_procs, index,
                             NULL);
                     break;

ompi/mca/btl/usnic/btl_usnic_proc.c

@@ -398,6 +398,9 @@ ompi_btl_usnic_create_endpoint(ompi_btl_usnic_module_t *module,
  * If we don't find a match, it's not an error: just return "not
  * found".
  *
+ * This routine transfers ownership of an object reference to the caller, who
+ * is eventually responsible for transferring or releasing that reference.
+ *
  * There is a one-to-one correspondence between a ompi_proc_t and a
  * ompi_btl_usnic_proc_t instance.  We cache additional data on the
  * ompi_btl_usnic_proc_t: specifically, the list of