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

[johnmhoran]

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.

[johnmhoran]

See also my 2024-03-05 fetchcode issue discussing several examples of exceptions that interrupt the flow of the relevant PURLCLI command and my approach -- logging, reporting in the output errors and warnings keys, and printing to the console -- to replace the interruptions from a raised exception.