Replace raw long counting with a Long2LongMap accumulator

[cplir-c]

Attempts to fix the fluid using 1 Bucket = 81k items issue.

I chose to use a Long2LongMap accumulator so that different AEKeyTypes with the same denominator could be summed in the same map slot, and avoid the internal-rounding issues that would be had if I divided all the values by their Unit denominators.

[62832]

We greatly prefer PRs like these to be submitted against the main branch targeting the latest version and not any previous version branches.

[cplir-c]

Seems it didn't help... still getting 81k

[cplir-c]

Tested using a water bucket -> lava bucket pattern that just goes into a trashing matter condenser. I requested 2 buckets and gave it 1 lava bucket.

[cplir-c]

I'll try some more tomorrow. Would it be ok for me to get it working first and then import the changes to 1.20.4 and 1.21?

[Technici4n]

I would do it using floating point numbers.

[shartte]

Generally for progress scaling, we can use the transfer unit we have in the key type (That is what we use to determine a how much a unit of work is for a given type of resource)

[Simba98]

I would do it using floating point numbers.

Alternatively, we may scale up the item type by AEFluidType.getAmountPerUnit() And then on GUI scale down. This can keep it int type, and more importantly, as financial programmers usually do, using int type will keep computing precise.