update V value manipulation

[Chengxuan]

Update the logic for calculating v value so that it can work with an RSV signature in which v is just the y parity.

The diagram and tables below show the changes:

Before the fix

Func \ Input V	A (0/1)	B (27/28)	C (2064/2065)	E (98112/119)
1 (expect A, B, C)	✅	✅	✅	✅ (throws unexpected V error)
2 (expects B)	🔴 (0/1)	✅ (27/28)	🔴 (2064/2065)	🔴 (98112/119)
3 (expects C)	🔴 (2010/2011)	✅ (2064/2065)	🔴 (4047/4048)	🔴 (100122/2129)
4 (expects A)	✅ (0/1)	✅ (0/1)	🔴 (2064/2065)	🔴 (98112/119)

After the fix

Func \ Input V	A (0/1)	B (27/28)	C (2064/2065)	E (98112/119)
1 (expect A, B, C)	✅	✅	✅	✅ (throws unexpected V error)
2 (expects B)	✅ (27/28)	✅ (27/28)	✅ (throws unexpected V error)	✅ (throws unexpected V error)
3 (expects C)	✅ (2064/2065)	✅ (2064/2065)	✅ (throws unexpected V error)	✅ (throws unexpected V error)
4 (expects A)	✅ (0/1)	✅ (0/1)	✅ (throws unexpected V error)	✅ (throws unexpected V error)

Key changes are:

• Align function 2, 3, 4 with 1: explicit error when the Input V is not expected (either widely adopted Y-parity or the values conforming to the corresponding rules)
• Align function 2 , 3 with 4: handle Input V with Y-parity as value.

[peterbroadhurst]

So my understanding here of your approach @Chengxuan is:

• The signature supplied can contain 0/1 or 27/28
• The code uses normalizeVToYParity on all code paths where the parity is needed, to normalize it to 0/1
• The EIP155 chain ID validation now uses the 0/1 version out of normalizeVToYParity

Given the sensitivity of this library interface, I want to really validate this with you that I've understood correctly.

• That none of the existing paths that accepted 27/28 successfully, (or 0/1 successfully) will now fail.
• That no returned signature formats will be affected

[Chengxuan]

@peterbroadhurst yes, I can confirm both statements are true.

I updated the main description with more details. And also added a new commit to fix SignTypedDataV4 as well. Missed it due to it's not in the same file as other functions.

[peterbroadhurst]

Thanks @Chengxuan - think the extra validation was worth it, given the number of consumers of this library that could be affected by a change.