Various degrees of read-only media

From the readme file:

> Various degrees of read-only media (to disable uploading, editing, cropping, or deletion)

The idea is that a provider declares what features it supports (via methods on its Provider class) and then AMF takes care of either disabling the functionality in WordPress or communicating the functionality to the provider. This allows, for example, a provider to simply declare that users cannot upload files and AMF takes care of everything.

One potential problem is that WordPress core doesn't use granular capabilities for media, so any changes that need to be made via adjustments to user capabilities might hit a problem. See https://core.trac.wordpress.org/ticket/41332

## File uploads

If file uploads are supported by the provider:

* Need a means for WordPress to pass an uploaded file onto the provider, preferably without it being put into place in the uploads directory
* Need to consider file uploads via:
- async-upload.php
- REST API `wp/v2/media` endpoint
- Direct call to `wp_handle_upload()`
* Presumably the provider also needs to support editing files (see section below) in order to provide the title, description, caption, etc.

If file uploads are not supported by the provider:

* Remove the "Upload" buttons shown in various places in WordPress
* Remove the "Upload files" tab in the media modal, note that this causes a blank screen when a user first opens the media modal and this tab is not visible, needs investigating
* Remove the "Select Files" button shown below the "No items found" message when there are no results
* Disable drag and drop upload handler, best achieved by [returning an error from the `wp_handle_upload_prefilter` filter](https://wordpress.stackexchange.com/questions/99248/disable-media-uploads-to-non-admin-users/105558#105558)

## Editing file data

This means editing of the metadata associated with a file, such as its title, description, and caption. For modifying the actual file via image cropping, see the image cropping section below.

There are three possibilities:

1. The provider supports editing file data and changes made on the attachment editing screen in WordPress should be pushed to the provider
- Need a means for changes made to an attachment to be passed onto the provider
2. The provider does not support editing file data and changes made on the attachment editing screen in WordPress only take effect on the local site
- No changes necessary, this is the default and current behaviour
3. The provider does not support editing file data and it should not be possible to make changes locally by editing the attachment, for example for compliance reasons
- Can be enforced at the user capability level

## Image cropping

Currently if an image is cropped WordPress makes a local copy of the file, thus allowing the remote provider to be bypassed.

If the provider supports image cropping:

* Need a means of passing the cropping coordinates and dimensions on to the provider and potentially being sent back a new URL for the file

If the provider does not support image cropping (probably most providers will not):

* Need to disable image cropping functionality in WordPress
- Edit Image link when a file is selected in the media modal
- Edit Image button in the media grid modal
- Inline cropping in the Image block type
- Site Logo
- Site Icon
- `wp_ajax_crop-image` action
- `wp.media()` when one of the states is a cropper ([example](https://github.com/WordPress/wordpress-develop/blob/e686cb1b0e7061477cc1b2f537f64e053366d0b8/src/js/_enqueues/wp/customize/controls.js#L4538-L4540))
- Header image controls with `Select and crop`

## Deleting files

There are three possibilities:

1. The provider supports deleting files, and attachment deletion should be pushed to the provider
- This is potentially a very destructive action and it might be that we simply don't want to support this
2. The provider does not support deleting files, and attachment deletions in WordPress only take effect on the local site
- No changes necessary, this is the default and current behaviour
3. The provider does not support deleting files, and it should not be possible to delete attachments locally
- Can be enforced at the user capability level

## "Insert from URL"

The `Image`, `Audio`, and `Video` block types support using a URL instead of a file from the media library. It's preferable to disable this capability when a DAM in use, but it might not be strictly related to a provider. There could be a use case for retaining or disabling this regardless of whether file uploads are supported.

Maybe implement via a separate filter instead of a declaration by the provider.