Decide how to handle exceptions raised by services consumed by the PURLCLI commands

In the absence of design feedback, I decided months ago that we do not want an exception to be raised when a PURLCLI command is run -- this would interrupt the process and is not desirable, I concluded. In place of that I added code to use a .log file shared by purldb and fetchcode/package.py that would be used to communicate exception messages back to purldb-toolkit, where they could be reported in the JSON `errors` and `warnings` keys. (We also need to include packageurl-python/purl2url.py in this communication line.)

I learned a short while ago that we do not want this approach and that we do want to raise exceptions. We need to discuss the implementation details before I start to revise the extensive code created to implement the logging approach.