Refactor and clean up the Access (download) API

This is a "technical debt" and legacy issue.

Access is one of the oldest APIs in the application, originally implemented in the context of DVN 3. There is a lot in the code that is archaic and cumbersome and hard to work with.
Prime examples:

• Unlike most of our other APIs, file downloads need to serve potentially massive amounts of data. So the content cannot be returned as a buffer or a string, and needs to be streamed. To implement streaming, in most places we are still relying on the code written for early versions of Jersey REST library; that requires providing standalone MessageBodyWriter classes (DownloadInstance.java, DownloadInstanceWriter.java etc.) It would be cleaner to switch to using javax.ws.rs.core.StreamingOutput (/api/access/datafiles, download-multiple-files-zipped, a newer API, uses it already).
• There's a system of OptionalAccessService classes, meant to support extra download options - extra formats/conversions and such. It was meant to be dynamic/possibly plugin-driven. It became hard-coded in the original Dataverse 4.0. And by now it only makes the code more confusing and difficult to work with.

Start by reading the Access download API entry points, including /api/access/datafiles, and the legacy DownloadInstance.java and DownloadInstanceWriter.java classes. Compare their streaming approach with the existing StreamingOutput implementation, then trace the OptionalAccessService classes and their hard-coded uses. Done requires a defined, tested cleanup scope for both download streaming and optional access services.