Add three new contracts:
* Compression I: RLE Encoding
* Compression II: LZ Decoding
* Compression III: LZ Encoding
as well as associated utility functions
Previously, edge order would stay constant while vertex order was
shuffled. This way, there is even less opportunity for a player to
reverse-engineer the initial bipartite graph.
Implemented a greedy 2-coloring algorithm to check whether a given
graph is 2-colorable. The algorithm is only used if the player
provides "[]" as their answer; other answers will be checked using
the previously implemented validation code.
Implemented the case for the 2-coloring solver to validate that
entered colorings are proper. Still needs a case for when no
solution exists.
Also, changed the data from type [number, number][] to
[number, [number, number][]], so that the number of vertices in
the graph can be the first parameter.
Implemented the generator for a new contract type. For now, has
a description and solution checker designed only for testing. The
generator creates a bipartite graph with random edges, then
attempts to add one additional edge without regard for the partite
sets. It then randomizes the vertices of the graph to make reverse-
engineering the original partite sets impossible.
The shuffling algorithm is adapted from stack overflow code, but
really, what isn't?
Various capitalization and punctuation fixes
Changed "Note" to "NOTE" to match other coding contracts.
Removed "encoded/decoded following hamming's rule" because I couldn't find references to hamming's rule (there are various things called Hamming's Rule, but they didn't seem relevant here). I believe that clause was just emphasizing that the binary string encoded as a hamming code, which we already know?
Rewrote the "return" text to include it should be a string.
*NOTE 4 could be removed, or kept for redundancy's sake
*"So MAYBE there is an altered bit" is also redundant, since note 3 already says a 55% chance, which means "maybe." Left, but could be removed.
