Add an exception class that can be used to tag an  exception as being a user-facing error message.  Set up a FastAPI exception handler that can forward these error messages to the client side.  Have RemoteButler  raise the corresponding exception when errors are received from the server.

Hoist MissingDatasetTypeError up to the top-level exceptions file, and mark it as as ButlerUserError so that it can be sent from the server to the client.  This allows removing some code specific to this exception type from RemoteButler.

In unit tests, we now convert unhandled server errors to a special exception class 'UnhandledServerError' that is not part of Butler's usual exception hierarchy.

The FastAPI TestClient by default passes unhandled exceptions up from the server to the client.  This is useful behavior for unit testing because it gives you traceability from the test to the problem in the server code. However, because RemoteButler is in some ways just a proxy for the server-side Butler, we raise similar exceptions on the client and server side. Thus the default TestClient behavior can mask missing error-handling logic.

The registry test suite in test_remote_butler.py does not yet have all error-handling logic in place, so it opts out of the new behavior.

Remove one-off code handling FileNotFoundError and 404s in RemoteButler, replacing it with the new error propagation framework.

LookupError is currently thrown from a variety of places for mostly-unrelated reasons, most of which don't need to be propagated to the server.  Give it a more specific name instead.

It turns out that DirectButler typically throws two different exceptions from get():
1. DatasetNotFoundError if the dataset can't be found in registry
2.  FileNotFoundError if the file itself cannot be found or under some other error conditions (some of which involve not being able to find the dataset in registry.)

Added test coverage for case #1, and fixed RemoteButler to comply with it.  Loosened the tests for some unusual error conditions to allow either of the two exception types, because RemoteButler doesn't have enough information available to replicate the DirectButler behavior.