version static unit test input data against protocols

[jevonearth]

Guidelines for writing unit tests.

For unit tests that uses static input that came from the chain, it will be useful to the reader to name the data (or variable containing the data) with the protocol of the data from which it originated.

Data shape may change over time with new upgrades, so making this information explicit should make it easier for our future selves to see what is under test.

Context/impetus: https://github.com/ecadlabs/tezos-ts/pull/22#discussion_r317212605

Draft for new "Unit-tests guidelines" documentation.

When writing tests for a function that takes sample data, the unit-test author should illustrate the origin of the input data. For example, if the developer is writing a unit-test for a hypothetical method is named parseOperation(), the unit-test should make clear what protocol the test fixture data is originating from.

For example:

• parseOperation(op_005) where the operation test fixture is congruent with an operation from the Babylon/005 protocol
• parseOperation(op_006) where the operation test fixture is congruent with an operation from the Carthage/006 protocol

Tagging unit tests that operate on functions

For code that deals with data that may change based on what protocol is being tested, the unit-test should be marked (Note, How should we mark these tests??) so that when we add new protocol support to Taquito, we can get a list of all unit-tests that require to have additional test-fixtures added for the upcoming protocol

[Innkst]

Related to #479

[jevonearth]

The next task for this is to review all unit-tests.

Categorize unit-tests into read and write Get constants is a read method and should have test inputs from all protocols Forging would only need to have inputs for the last, current and future protocol. We remove support for older protocols from things like forging, as there is minimal to no value in maintaining such code.