API: create native method to return IDL definitions

[Galen Charlton]

As it happens, there's no native Evergreen method to return IDL definitions. Instead, if a client needs to deal with the IDL, it needs to do something other than making an OpenSRF request to get at the definitions. (I.e., fetch from /reports/fm_IDL.xml (which requires parsing XML) or /IDL2js (which is designed for Javascript clients)).

For integrators who aren't using the upcoming OpenAPI layer or are accessing the API from a web app, a couple native methods to deal with the IDL may smooth things a bit.

- fetch IDL definitions for selected classes in JSON format
- translate a fieldmapper object from array-based serialization to index-based serialization

[Galen Charlton (gmc)]

Another idea for a method: something that takes a service, method name, and parameters, and calls it, but performs bidrectional translation from array-serialized fieldmapper objects to hash-serialized ones.

[Mike Rylander (mrylander)]

Just jotting a couple thoughts down while it's fresh...

The transformation described would be easy on the way out of a method call, but hard on the way in because we haven't made consistent use of OpenSRF's parameter typing infrastructure. However, we can tell the system about the registered object type of each parameter (though there is some complication here with array and hash params containing FM objects), so it should be possible to do this over time as specific methods are needed for integration.

The code changes needed to transform Fieldmapper objects to bare hashes (and vice versa) exists in the prototype OpenAPI translator right now, and should really be moved into Evergreen's Fieldmapper package.

https://github.com/EquinoxOpenLibraryInitiative/eg-restful-api-experiment/blob/main/eg-api.pl#L1366