Add fixAMMv1_2 amendment

[gregtatcam]

High Level Overview of Change

Add fixAMMv1_2 amendment:

• It adds reserve check on AMMWithdraw
• It generates AMM max offer if changeSpotPriceQuality() fails

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Refactor (non-breaking change that only restructures code)
• Performance (increase or change in throughput and/or latency)
• Tests (you added tests for code that already exists, or your new feature included in this PR)
• Documentation update
• Chore (no impact to binary, e.g. .gitignore, formatting, dropping support for older tooling)
• Release

Test Plan

Added unit test to check reserve requirements on AMMWithdraw.

[codecov]

Codecov Report

Attention: Patch coverage is 96.66667% with 1 line in your changes missing coverage. Please review.

Project coverage is 77.6%. Comparing base (d57cced) to head (fb32608).
Report is 1 commits behind head on develop.

Files with missing lines	Patch %	Lines
src/xrpld/app/paths/detail/AMMLiquidity.cpp	80.0%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff            @@
##           develop   #5176     +/-   ##
=========================================
- Coverage     77.6%   77.6%   -0.0%     
=========================================
  Files          779     779             
  Lines        65975   66006     +31     
  Branches      8170    8172      +2     
=========================================
+ Hits         51187   51211     +24     
- Misses       14788   14795      +7     

Files with missing lines	Coverage Δ
include/xrpl/protocol/Feature.h	100.0% <ø> (ø)
src/xrpld/app/tx/detail/AMMClawback.cpp	100.0% <100.0%> (ø)
src/xrpld/app/tx/detail/AMMWithdraw.cpp	96.2% <100.0%> (+0.2%)	⬆️
src/xrpld/app/tx/detail/AMMWithdraw.h	100.0% <ø> (ø)
src/xrpld/app/paths/detail/AMMLiquidity.cpp	84.7% <80.0%> (-0.2%)	⬇️

... and 8 files with indirect coverage changes

[ximinez]

LGTM

[thejohnfreeman]

Normally these checks are supposed to use the "prior balance", i.e. the balance of the account before the transaction started executing. I just want to note that we're making an exception here. In fact, it would be easier if we could ignore the "prior balance" everywhere. The context for most helper functions is just the ApplyView, which does not track the "prior balance" of any account. (The transaction function in this PR is not a helper, but one day it might be.) Helpers that require a prior balance demand that it be drilled through the caller as a parameter.