Clarify how firstMatch capabilities are validated against alwaysMatch

According to the spec, once capabilities have been validated, we iterate firstMatch list, trying to merge and match the capabilities. As soon as we have a match we return the merged capabilities. This means that there might be duplicated entries in first and always as long as any previous one matches. This is what happens in test merge.py::test_merge_invalid, that includes an empty object as the first item of every firstMatch list. The test passes in firefox, because it first checks that there isn't duplicated entries in first and always and then it does the merge and match. If that was the idea, then we should fix the spec, probably adding a step before the iteration to do the check, and remove the check from the merge algorithm. Otherwise we should fix the test by removing the initial empty object from the firstMatch list.

Start with merge.py::test_merge_invalid and the specification steps for validating capabilities and merging firstMatch with alwaysMatch. Determine whether duplicate entries must be rejected before iteration or whether the test is wrong, then align the specification and test so the validation and merge behavior agree.