…ists`, `BadRequest`, `PermissionDenied`, `InternalError`, and others

Improve the ergonomics of SDK, where instead of `except DatabricksError as err: if err.error_code != 'NOT_FOUND': raise err else: do_stuff()` we could do `except NotFound: do_stuff()`. Additionally, it'll make it easier to read stack traces, as they will contain specific exception class name.

# First principles
- do not override `builtins.NotImplemented` for `NOT_IMPLEMENTED` error code
- assume that platform error_code/HTTP status code mapping is not perfect and in the state of transition
- we do represent reasonable subset of error codes as specific exceptions

## Open questions

### HTTP Status Codes vs Error Codes

1. Mix between status codes and error codes (preferred)
2. Rely only on HTTP status codes
3. Rely only on `error_code`'s

One example is `BAD_REQUEST` error code that maps onto HTTP 400 and to `except BadRequest as err` catch clause. But `MALFORMED_REQUEST`, `INVALID_STATE`, and `UNPARSEABLE_HTTP_ERROR` do also map to HTTP 400. So the proposal is to remap the MALFORMED_REQUEST to `BadRequest` exception.

Another corner-case is UC:
- 'METASTORE_DOES_NOT_EXIST': NotFound,
- 'DAC_DOES_NOT_EXIST': NotFound,
- 'CATALOG_DOES_NOT_EXIST': NotFound,
- 'SCHEMA_DOES_NOT_EXIST': NotFound,
- 'TABLE_DOES_NOT_EXIST': NotFound,
- 'SHARE_DOES_NOT_EXIST': NotFound,
- 'RECIPIENT_DOES_NOT_EXIST': NotFound,
- 'STORAGE_CREDENTIAL_DOES_NOT_EXIST': NotFound,
- 'EXTERNAL_LOCATION_DOES_NOT_EXIST': NotFound,
- 'PRINCIPAL_DOES_NOT_EXIST': NotFound,
- 'PROVIDER_DOES_NOT_EXIST': NotFound,

### Naming conflict resolution

We have three sources of naming:
- `error_code`
- HTTP Status
- Python builtin exceptions

We still have to define which name takes the precedence.