fix: Use correct unit for file sizes and fix user quota

[susnux]

Summary

We always used binary file sizes (base 2, meaning 2048 bytes = 2KiB), but we added the wrong unit (we used the decimal (base 10) unit e.g. 2KB).

This fixes the user management showing a wrong quota (#38874 for master)

Also the OC_Helper now supports base 10 and base 2 in computerFileSize, for backwards compatibility it defaults to force even units like KB to be binary.

Screenshots

Screenshot	comment
	As discussed during the Nextcloud conf, we always expect the user to mean the binary size (mostly they are confused by windows using the wrong unit)
	Quota is now displayed correctly
	The file list automatically adapted to the correct unit

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[susnux]

cc @sorbaugh and @AndyScherzinger

The problem:

• On Nextcloud up to (including) 26 we used decimal units like 10 KB or 20 GB but we always meant 10 KB = 10 * 1024 bytes and not 10 KB = 10 * 1000 bytes.
• On Nextcloud 27 there was a regression (@nextcloud/files) that switched to even decimal values, meaning 10KB = 10 * 1000 bytes but our backend was and is always using binary values (1024).
• On Nextcloud 27.1 we patched this and reverted back to binary values (10* 1024) but with decimal units (KB instead of the proper KiB).

But for current master the frontend is still broken, we have to options:

1. Everything stays like it was on Nextcloud 26 and below, this requires the @nextcloud/files library to be adjusted again.
2. Move to decimal values (we should not do this the only people doing this are hard drive manufacturers and Apple)
3. Show the proper units (KiB instead of KB, GiB instead of GB...) this is what this PR is about.

From my point of view only 1 and 3 are really considerable solutions.
Pro 1:

• Everything stays the same UI wise
• Windows is using the wrong units for decades now, so the majority of users are used to them
  Con 1:
• See the confusion in the linked issue, having one unit used for multiple different things confuses

Pro 3 (this PR):

• It is clear what unit and file sizes to expect, so less confusion
  Con 3:
• Non technical users might choke on the i in the unit (but probably it will even not attract attention)
• Changing UI

[sorbaugh]

While it's true that lots of users are conditioned to read KB, GB, etc, I think switching to the correct units would be a "soft enough" change UX wise so I would vote for option 3 (but would be fine with option 1).

[jancborchardt]

I’d say it’s best in this case to go with what Windows does since @susnux as you say that is what the majority of people are used to. Yes it is not correct, but it is sort of convention on a topic where many people are confused anyway.

[sorbaugh]

I don't have a strong opinion on this, so option 1 is fine as well if we can foresee that option 3 would be confusing to people.

[susnux]

It was decided to keep current style.