Stop using DropzoneJs beta

Problem/Motivation

The desktop-file-drag feature (drag a file from the OS onto the page to create
or replace a media block) was built on the contrib dropzonejs module.
dropzonejs depends on enyo/dropzone 6.0.0-beta.2, which is
not published on packages.drupal.org. Every consumer site therefore
has to add a custom Composer repository entry pointing at a GitHub archive — a
recurring source of install friction for the + Suite recipe.

In practice dropzonejs contributed very little here. The server
contract (a multipart file POST returning a Drupal AJAX response) was
already framework-agnostic, drag detection (dragenter/over/leave/drop)
and media-type compatibility checking were already implemented natively, and the
Dropzone instances were used only as an XHR transport. The new-media
dropzone was even an inert Dropzone bound to a detached element.

Proposed resolution

Remove the dropzonejs module and enyo/dropzone library
dependency and own the browser → saved-file pipeline directly.

API changes

• The MediaDropzoneJs controller is renamed to
  MediaUpload (same namespace). Dependents that resolve it by class
  name must update — e.g. lb_plus NewMedia.php (coordinated
  change).
• The dropzonejs/dropzonejs library is no longer a dependency of the
  edit_mode library; dropzonejs is no longer required.

User interface changes

Drag-to-upload behaviour is unchanged for users, with the addition of an upload
progress bar that shows percentage during upload and a "Processing…" state while the
server creates the media and rebuilds the layout.