Fix EscrowFinish fulfillment and condition parsing

[nkramer44]

Fixes #513

As seen in transaction 138543329687544CDAFCD3AB0DCBFE9C4F8E710397747BA7155F19426F493C8D, sometimes EscrowFinish transactions can show up in validated ledger transaction sets with an invalid fulfillment or condition. We added a fulfillmentRawValue and conditionRawValue, and normalization functions to try to make fulfillment() equivalent to fulfillmentRawValue and condition() equivalent to conditionRawValue in #483. However, we missed a special case where the fulfillment or condition could be well formed in the first 32 bytes, but contain extra bytes afterward (in the case of 138543329687544CDAFCD3AB0DCBFE9C4F8E710397747BA7155F19426F493C8D, the fulfillment is duplicated), which causes an exception to be thrown by the normalization function.

This PR fixes this issue by checking that the parsed fulfillment or condition is equivalent to the fulfillment/condition raw value. If it is not equivalent, we will not set fulfillment or condition. If it is, we will.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 91.66%. Comparing base (2a68c4a) to head (ab75466).

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #512 +/- ## ============================================ + Coverage 91.65% 91.66% +0.01% - Complexity 1774 1776 +2 ============================================ Files 365 365 Lines 4948 4956 +8 Branches 408 410 +2 ============================================ + Hits 4535 4543 +8 Misses 280 280 Partials 133 133 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.