SDK specification and docs

## Goal:
The main goal is to create an SDK Specification Document that will serve as a building block for developers/community to develop their language-specific SDK (e.g. JS SDK, Go SDK etc.)

The overall target goal is divided into two phases;
**Phase 1** - Identify the endpoints, categorize them into load-bearing/fundamental and info only buckets, group them as fundamental building blocks, detail and document
**Phase 2** - Specifications about serialization interaction with JSON RPC

## Plan, Timeline and Acceptance Criteria:
### Plan of Attack as listed by @ACStoneCL;
> SDK Plan of Attack
> **Goals**:
> 1. Create a list of requirements for bringing an SDK into compliance.
> 2. The list can then be used by SDK devs to bring their SDK into compliance.
> 3. Establish an “SDK Specification” page within the documentation, clearly
> labelled.
> 4. Open RPC covers ‘outer’ structure – need to cover ‘interior’ formatting of
> binary strings byteswrapped/deserialization of same.
>
> **Initial Steps**:
> 1. Parse JSON RPC self-documentation
> 2. Determine “Fundamental” versus “Informational”
> 3. Detail and document fundamental endpoints.
> A. Serialization to interact with JSON RPC at various points. Specifically,
> responses that must be deserialized using ToBytes/FromBytes
> 4. Clarification/pointing to the right information
> 5. Liaison with Jan and Mark G as test ‘users’/Acceptance testers due to their
> having previously authored SDKs.
>
> **Secondary Steps**:
> 1. Take the above framework and include “Informational” nice-to-haves beyond the
> fundamental endpoints.

### High-level timeline
- At a high level start SDK requirements alignment in Sprint: Feb 8 - 22.
- Produce Phase 1 in Sprint: Feb 22 - Mar 8
- Repeat the same approach for Phase 2 in subsequent sprints

### Acceptance criteria:
Seek review support from @momipsl and @hoffmannjan. Approach envisaged - Act as users/acceptance testers of the specification

Consult the progress with @momipsl and @hoffmannjan