ndk: Rework media error types

[MarijnS95]

CC @paxbun

• Clean up the names: we're already in the ndk crate so no need to repeat that in the type name;
• Make the types available outside the media module, so that they can be used in AMidi bindings which are not located inside libmediandk.so (but libamidi.so);
• Add documentation comments;
• Guard dead_code helper functions with the right feature bound.

[MarijnS95]

Thinking of doing the same little tweaks to BitmapResult and friends.

[paxbun]

LGTM! By the way, construct or construct_never_null emit unused warnings when both media or midi are not enabled. Is that okay? IIRC, I tried to put some #[cfg(...)] to remove those warnings, but we kept it unchanged because of this rewriting.

[MarijnS95]

Yes indeed. It has bothered me too, but not enough to come up with a more restrictive cfg bound. Those are generally error-prone and would require extensive checking of all media, api-level-24, api-level-26, and later midi combinations of features in the CI.

With this PR MediaError::from_status() is also added to the list, fwiw :)

[MarijnS95]

I'm considering at least constraining this with media, then you can add midi to it in #353.

[MarijnS95]

@paxbun done, moved and fixed the cfg feature bounds. You'll have to add midi to the top-level #![cfg(feature = "media")] -> #![cfg(any(feature = "media", feature = "midi"))] but can hopefully leave the other cfgs intact as they automatically get enabled via "midi" -> "api-level-29" -> "api-level-24".

Though as you don't use construct_never_null(), this might need yet another bound :(

[MarijnS95]

Otherwise I might as well switch back to #[allow(dead_code)] (while still guarding the module as a whole) and document that the cfgs are nontrivial and would be hard to test and maintain all combinations.

[MarijnS95]

Though as you don't use construct_never_null(), this might need yet another bound :(

Yup it does :(

[paxbun]

I also think guarding the whole module with cfg and adding #[allow(dead_code)] to each function is the best now. This would be the case where we should use explicit allow.

[rib]

looks good to me!