Improve error/workflow for attempts to re-load the same pcap

[philrz]

If I've previously done a brimcap load of a pcap of a particular filename, and attempt it again, the error I see as a user:

$ brimcap load -s wrccdc -root ~/brimcap-root ~/wrccdc.pcap 
error writing brimcap root: symlink /Users/phil/wrccdc.pcap /Users/phil/brimcap-root/wrccdc.pcap: file exists

The fact the Brimcap root consists of symbolic links is an implementation detail that the user probably shouldn't need to be aware of in order to understand what went wrong here. A few things come to mind:

1. The error message could be improved to something like "a capture file named wrccdc.pcap already exists in the brimcap root"
2. Perhaps we need a command (brimcap rm?) that unlinks files from within the Brimcap root
3. So the user can review what's in the root (e.g. to see if the conflicting wrccdc.pcap is the same one they're trying to load, or just to review what's in there before deleting stuff) perhaps they also need a way to list information about what's already in the root (brimcap ls?)
4. There's the potential for a user to load different files of the same name from different locations in the filesystem. @mattnibs and I talked about this offline and he acknowledged that at some point we could do something like have the contents of the Brimcap root be unique (e.g. filenames based on hashes) with metadata that points to filesystem locations. That said, at the moment I do find it mildly convenient to be able to ls -l the contents of the Brimcap root and see what's in there, so this would probably further make the case for something like the brimcap ls proposed above so the user can see a processed summary of what's in the root.

[philrz]

Thanks to the changes in #37, the error shown in this issue no longer happens. Instead a re-load of the same pcap completes successfully, generating duplicate records in the destination Space. It would likely be a mistake if a user were to do this, so #45 has now been opened to consider if we should warn/prevent this somehow. Also, the ability to maintain the Brimcap root through commands like brimcap ls and brimcap rm still seems like it would be handy, so #46 has been opened to track that.