docs: (internal) design standard for APIs exposed via system contracts

[david-bakin-sl]

We've learned over time that there are impacts to how the methods in system contracts are declared - i.e., the signature. (And sometimes we don't learn the impact until much later, unfortunately.)

We should maintain an "API standards"/"API coding style" document - a checklist basically - of how (future) methods should look.

Suggestions initially for consideration:

• discussion of use of int64 vs uint64
• whether or not consistent use of response codes in return results is desireable (as opposed to, say, returning the result of a method as a bare boolean or something like that.
• difference in signature for same method functionality between system contract and proxy contract

This document should include other considerations for what needs to go into a HIP, besides methods (and their signatures). E.g.,

• New response codes needed for return values of methods must be in a HIP before they can be added to the protobuf specification

[david-bakin-sl]

@Nana-EC, @lukelee-sl - FYI