Update behavior for DELETE requests to concepts and references

[paynejd]

The OCL API wiki states that a DELETE request actually just sets the "retired" attribute of a new concept or mapping version to true. In the future, we plan to support hard deletes of concept or mapping versions that are not already members of a repository version. These two approaches both being supported via a DELETE request is inconsistent behavior and we may want to choose a different method for retiring concepts and mappings. Note that an alternative method for retiring concepts and mappings is already supported by simply doing an update (eg PUT).

Let's discuss the desired behavior in an upcoming OCL architecture call

[paynejd]

Note possibility of implementing a purge parameter for clients to request hard deletes. This was described in #10.

[paynejd]

See note from #67 (which is now closed) about possible issues with "soft deletes" -- need to determine if there are incorrect behaviors brought over into oclapi2 from this.

It is possible to inactivate any object (soft delete it). It will no longer appear in searches, however it will still be present in mongo and can be activated again, if needed. There are a number of issues with inactivation:

• inactivated objects are still considered when validating other objects, e.g. you cannot create a new org with the same name, if there's another inactive org with that name. Same may apply to sources/collections/concepts/mappings.
• when a container like org or source is inactivated, all objects within that container should be inactivated.
• when a collection is inactivated, all references should be inactivated, but not the referenced objects

[paynejd]

Also from #93 (now closed):

Example, a user is creating lots of concepts and mappings while they are working on a new release and they are then deleting a few that were made on accident or were incorrect that are not part of a previous release. It is appropriate for them to be able to delete these.

Consider using the ?purge=true url parameter, though open to other options.