Gracefully handle already removed objects

[sleepybishop]

Fixes #81.

Adds a safety check to NormObjectTable::Remove in the USE_PROTO_TREE implementation to verify that the object exists in the tree before attempting removal.

When a user calls NormObjectCancel on an object already aborted internally by the NORM protocol, it will now gracefully return false rather than crashing via a tree.Find assertion or risking a use-after-free.

[bebopagogo]

Is this the root cause of the issue that was initially reported regarding the ProtoTree issue? I.e., during shutdown incomplete objects are aborted and removed which races with user API calls to Remove()? I'm trying to understand the sequence of events. For NORM_OBJECT_DATA, it may be important the API notifications work cleanly to allow for release of attached memory allocations ... I am approving this but taking a self action to review that to see if there is a race condition I need to fix above and beyond this safety measure

[sleepybishop]

Maybe not, I may have chased the wrong rabbit. I think RX_OBJECT_NEW remained queued while Sync() internally aborted and removed it, but the event was queued and so the application later received a valid handle and called NormObjectCancel().