When scripts receive a DataTransferItem from any IDL method, the spec
requires we return the same DataTransferItem for a particular item in
the drag data store. Meaning, we cannot just create these on the fly as
needed.
To do this, we store a list of DataTransferItem on the DataTransfer
object. We will return one of these objects any time one is requested by
a script.
It feels a bit weird to have the DataTransfer object store: the drag
data store, a DataTransferItemList, and a list of DataTransferItem. But
this is how other engines implement this as well. It basically has to be
this way as DataTransferItemList is just a proxy to the DataTransfer -
meaning, DataTransfer is the source of truth for all IDL access.
The IDL constructor has to take separate steps than a DataTransfer that
is internally constructed. Notably, an IDL-created object has its own
drag data store, and that store is placed in a read-write mode.
Ownership of the drag data store is a bit weird. In a normal drag-and-
drop operation, the DragAndDropEventHandler owns the store. When events
are fired for the operation, the DataTransfer object assigned to those
events are "associated" with the store. We currently represent that with
an Optional<DragDataStore&>.
However, it's also possible to create DataTransfer objects from scripts.
Those objects create their own drag data store. This puts DataTransfer
in a weird situation where it may own a store or just reference one.
Rather than coming up with something like Variant<DDS, DDS&> or using
MaybeOwned<DDS> here, we can get by with just making the store reference
counted.
This does not implement any of the IDL methods, but GitHub requires the
interface exists to upload files via an <input type="file"> element.
Their JS handles uploads via this element and via drag-and-drop in one
function, and check if the uploaded file is `instanceof DataTransfer` to
decide how to handle it.
