Some API calls throw 500 errors instead of intended codes

As discovered in #7588, some of the existing API calls incorrectly throw a WrappedResponse which is then caught by the ThrowableHandler class. It looks like these may have originated from incorrect adaptation of methods that use the AbstractApiBean.response(DataverseRequestHandler) method, e.g. edu.harvard.iq.dataverse.api.Info.getTermsOfUse(), where the response method correctly unwraps the WrappedResponse.

This issue is nominally about finding and fixing the methods that are returning incorrect response codes. They should be findable via a search for API methods that 'throw WrappedResponse' - any top level method (one that corresponds to an endpoint) that does this is either incorrect or doesn't actually throw a WrappedResponse under any circumstance.

After tech hours discussion about the best way to fix these methods, the general consensus was to work to adapt them to avoid using WrappedResponse and instead to have classes that now generate a WrappedResponse to throw the appropriate subclass of javax.ws.rs.WebApplicationException. This leverages a standard Java RESTful services mechanism rather than a Dataverse-specific mechanism. (The expectation is then that new API calls should use WebApplicationExceptions as well. It may also make sense to convert some existing methods: for example, the findUser* methods currently throw a WrappedResponse and if they are changed to send WebApplicationExceptions to fix some of the API calls that are not working now, it might make sense to also change API calls that were using try/catch blocks to unwrap the WrappedResponse (so they were working, but now don't need to have the try/catch).

Search the API methods for "throw WrappedResponse", then compare top-level endpoints with AbstractApiBean.response(DataverseRequestHandler), using Info.getTermsOfUse() and ThrowableHandler as the initial references. Review the affected methods and the findUser* methods, then verify that affected API calls return their intended response codes through WebApplicationException rather than incorrect 500 responses.