Offer per-platform guidance for running custom Zeek/Suricata

[philrz]

With the direction things are heading in #11, it's looking like (at least for a while) we'll be publishing per-platform Brimcap artifacts that include embedded Zeek/Suricata binaries that reliably turn pcaps into logs that will import easily into a Space and be well-presented in Brim. However, part of what we're trying to achieve with Brimcap is to make it easier for users to bring their own custom Zeek/Suricata (and potentially additional pcap processing tools). Therefore, it'll be helpful for us to provide some guidance to get users started on that path.

We already have some coverage in the README in the way we point macOS users at brew, and no doubt we can do the same with apt or yum on Linux. However, when simply "playing user" ourselves in attempting to use Brimcap in this manner, we've already bumped into a couple problems that users would be likely to hit if we just hand-wave at brew/apt and call it a day, e.g. #4 which affects macOS users that install via brew, and #13 that affects both macOS and Linux. The question of running zkg via virtualenv vs. sudo pip3 install also may be worth touching on. I'm guessing we'll bump into more topics over time as users try it out and give us feedback. We can probably cover these all through some combination of per-platform-style README docs and maybe some helper install scripts that execute the necessary commands on out-of-the-box macOS/Linux systems to install the versions in the same way our CI does when we test. For Windows, we'll probably want to set expectations that they'll be limited in how much they can customize, and we can point to the open Zeek issue that's tracking the potential for formal Windows support in case they want to weigh in their with a 👍  or contribute to the effort.

Beyond known bugs and limitations, we'll probably also want to add other guidance regarding customization, e.g. what to expect if they modify the Suricata shaper to let through all records other than event_type of alert, or let through time-free Zeek logs like loaded_scripts. I think this would provide a decent intro to the concept of shaping and could be cross-referenced with whatever we write for #8.