Deletemap subcommand: proposed renaming and default behavior

[sbesson]

See #11 (comment)

There is some known variation between the various context classes invoked by metadata populate --context. Although the signatures of the constructor is maintained in sync, many of the options are really targetted at one context only.

DeleteMapAnnotationContext is probably the most obvious example. Unlike the other contexts, it uses the loops and ms options for the graph operation on the server. In addition, populate --context deletemap feels a bit contradictory from a semantic perspective.

A proposal would be to:

• separate the DeleteMapAnnotationContext API the other population contexts, eventually migrating it to a separate module
• deprecate metadata populate --context deletemap and replace it by a more explicit metadata delete subcommdn (maybe even metadata delete --bulkmap to mirror the populate command)
• fix the default deletion command behavior to properly handle infinite waiting

[joshmoore]

metadata delete is sufficiently broad that it might help to drive the renaming here. e.g.: bulkmap delete and mapannotation delete or metadata delete maps etc.