Update and remove should support arbitrary selectors and {multi: true}

[mattmccutchen]

Starting an issue thread for this enhancement that is already on the roadmap:

The update and remove methods should support arbitrary selectors (not just a specific ID) and update should support {multi: true}, at least on the server. On the client, it may be most sensible to keep the current restrictions, mirroring the restrictions of the normal Meteor API for collection writes from the client.

As maybe you realized, iterating over matching documents isn't too bad; I have a prototype implementation of that part that I drafted for my app but didn't end up using. The messy part is handling the return value and the callback. But if the code is restructured in either of the ways I suggested in #79, that will become easy.

Edit: I realize I tacitly assumed that a update or remove with an arbitrary selector was to be represented in the history as individual updates or removes for the affected documents. That may not be faithful to the intent of the application if the transaction is redone and the set of matching documents is different than it was originally. But even if we redo the operation using the original selector, that might not be good enough if the code that performed the original transaction would have taken different branches based on the new database state. So should we just reexecute that code? That would be one approach to design an undo/redo layer (which many applications take), but it's not the approach this package takes. Once we agree that maintaining any semantics with a nonlinear history of database updates is dicey, then maybe it's reasonable to represent the history in terms of specific documents.