fix(calc): rework calculating fees

[TarikGul]

This PR focuses on removing CalcFee from sidecar completely, and now relies on rpc.payment.queryInfo in order to retrieve the partialFee of an extrinsic.

Notes

1. Some e2e-tests needed to be adjusted, our implementation of CalcFee was incredibly accurate, but in some cases there was a marginal difference between results.

2. Excluding the few marginal differences in partialFee all e2e passed, meaning we are maintaining historical integrity and no longer need CalcFee.

3. This PR removes ALOT of core code, tests, and types which is awesome. It really cleans up the /blocks endpoint and makes it more digestible.

4. It should now be relatively straightforward to implement this feature: Fetch tx fee from onchain events #756

5. A follow up PR should be made to remove calc from sidecar, place it in its own repository and archive it.

closes: #936
closes: #935

[niklasad1]

@TarikGul what's up with all these changes of partialFee?

[TarikGul]

So here's my thought on this: @substrate/calc is part of older substrate legacy code when it comes to calculating fees. For a majority of our e2e-tests the partialFee we had before matched perfectly to the new partialFee we retrieve from the rpc method payment::queryInfo, but for the few cases that failed the accuracy was off by at most 4 decimal places (which is super tiny). I'd be lying if I said I knew exactly what the issue was when it came to our intrinsic calculations. But, moving forward IMO the substrate rpc method is more reliable/accurate and if there was an discrepancy it was with the way we were either:

a) pulling the necessary, encodedLength, multiplier, perByteFee, or weights per runtime.

b) Handling calculations and what runtime was using what fee calc version.

Either way, moving off of @substrate/calc, and relying on the intrinsic calculations provided by the node seems like the right move given these results.

[niklasad1]

LGTM, but would good to know if these partialFree changes breaks something 🤔