Standardize metadata handling

Many of these API endpoints return one or more metadata objects. We handle them differently in different places, which is not ideal.

In `drop_dir`, we flatten the nested output and coerce to a tibble, one row for each object.
In `drop_search` and `drop_get_metadata`, we return the nested list as parsed from JSON.
I think `drop_delete` returns metadata too?

We should handle them the same everywhere, regardless how many are returned. I think we all love tibbles, but it also might be odd to return a one-row tibble. Regardless, we should consider whether flattening the list is the best way to handle nested fields, or if we should use list-cols instead.

Another option would be to create our own R-side metadata objects, which could then be coerced to tibbles with methods, as well as any other methods that might be useful. I have little idea about how this would work, but as we expand the API coverage, bundling up some objects might simplify common operations, rather than relying on list indexing. But it might also be totally not worth the effort.

Compare metadata handling at the `drop_dir`, `drop_search`, `drop_get_metadata`, and possibly `drop_delete` entry points. First map the returned shapes and how nested fields are represented; the work is not ready to implement until the project agrees on a consistent representation, including the single-object case and whether to use flattened tibbles, list-cols, or R-side objects.

Written by the indexing model from the issue text.