Add agreement level for each cell

[flbulgarelli]

We should be able to have agreement level marks per each cell, that complement row agreement levels. We should also be able to support multiple values per each cell and to compute those values an agreement levels.

[flbulgarelli]

🆙 Agreement should be stored this way in each row:

{
    "rows": [
        {
            "scientific_name": {
                "value": "Mus Musculus",
                "agreement_level": 3 // cell agreement level: this cell has been seen / approved 3 times
            },
            "common_name": [
                {
                    "value": "Mouse",
                    "agreement_level": 2 // cell agreement level: this cell has been seen / approved 3 times
                },
                {
                    "value": "Rat",
                    "agreement_level": 1 // cell agreement level: this cell has been seen / approved 1 times
                }
            ],
            "$agreement_level": 3 // row agreement level: this row has been seen / approved 3 times
        }
    ]
}

[flbulgarelli]

In order to incorporate this data, tablemerge should be able to:

1. Determine if the same row has been seen in both tables that are been merged or if rows are (heuristically) completely different.
2. If the rows are different, we should not try to merge them, but instead add them to the merged table independently, one after the other. Each one will get a row $agreement_level of 0, or keep the original agreement level, if they already had it. cell's agreement_level is not affected
3. If the rows are considered the "same" row, they are merged and each similarity is analyzed individually and cell's agreement_level is calculated.

Calculating those agreements should be easy when tables have the same columns and the same number of rows, since we could do a direct zip. This is the first and easiest scenario we need to address. Then we could focus on more complex scenarios:

1. when column names are the same, but row numbers don't match. In this scenarios, although lengths will not match, we should still assume that relative ordering of rows is not affected. E.g. if table A has columns a b c and table B has columns d e f g, we must always grant that merged table rows coming from A and B keep their relative ordering. E.g. it could be abcdef, abdcefg but never acdbegf. That should also work as a hint for detecting similar rows.
2. when columns don't match (this is probably a too big problem and should be addressed separately: Handle tables with different column names #9)

[flbulgarelli]

Both for heuristically comparing rows and cells, we could use some the same alternatives discussed in #9: jackard indexes, fuzzy hashing, levenshtein distances, semantic vectorization / embeddings, etc. We could also just start with plain old normalized equals-ignore-case tests.

Also, the problem of detecting if a row is new or just a (maybe modified) copy of another is analogous to a sequence alignment problem - but instead of aligning single elements, we are aligning rows. Also, we should assume if matching row exists, it is in the same fragment (page), which will make the alignment more robust and faster.