bpd: database update could be async

The real MPD updates its database asynchronously when a client sends an `update` command over the protocol. It creates a background task with an identifier and returns that immediately to the client. The client can correlate that identifier with the output of the `status` command to track the request.

BPD currently updates its VFS (it's view of the beets database) synchronously on `update`. Because it doesn't send that task identifier in the response, clients such as beet's own `mpdupdate` break. We at minimum need to send such a response, and possible add the corresponding field to the response to `status`.

Building the VFS is currently quite slow. We could consider doing this in the background, or maybe just avoiding that complexity and finding a new data structure with better performance.

Note that beets actually notifies bpd through plugin events when the database changes (and therefore the VFS needs updating) so we could do this automatically and make the actual `update` command a no-op (see #168).

Start by tracing BPD's handling of the `update` and `status` commands and the VFS-building path. Compare the protocol behavior described here with the existing `mpdupdate` client expectations and related issue #168; done requires an agreed design for task identifiers, status reporting, and background or event-driven VFS updates.

Written by the indexing model from the issue text.