Fix reported size issues in builtin DIR command

[maxpat78]

• when a SMB share is mounted to a drive letter, the correct free space is shown
• -freesize switch is honored
• also, it purges the 1919 MB freesize cap limit

(tested WIN32 version only, with an 8TB VHDX drive)

Closes #4004
Closes #4258

[Torinde]

Great!
I can't test that immediately - I'll report back when I can.

[Torinde]

Partial testing:

• Reporting SMB free space - works (tested with below 1TB), but that worked also before, since Update drive_local.cpp #4255. Did you change something now?
• mount ... -freesize ...
  
  -- good: it goes beyond 1919MB/2GB
  -- wrong: there is a limit of 2047MB when a higher cap is specified
  -- strange: without cap it goes to almost the VHDX maximum, but File explorer shows bigger free space

Haven't tested yet:

• convertdrivefat=true and convert fat free space (and booting MS-DOS 7.10)

Can't test:

• SMB share with more than 2TB free

[maxpat78]

@Torinde The free size is limited in other ways, as you can see:

Perhaps I have to remove all that code?

For the SMB share, I created a network share on the same 8 TB VHDX I've mounted for the other test.

[maxpat78]

Further notes for possible code reorganization:
dos_programs.cpp: 1170ss (MOUNT -freesize)
The intent is to create a "fake" FAT disk geometry and translate the free space in terms of it (it is expressed in clusters): at this time, no information is known about the real emulated disk!

localDrive::localDrive constructor takes these fake params, passed as uint16_t and uint8_t. Max possible size is 65535 clusters and, we know, DOS knows very little about 4Kn sectors or big (>32K) clusters...

In drives.h, struct allocation (member of localDrive) should perhaps be enhanced to 64-bit, to track modern disk quantities. Appropriate members (AllocationInfo, AllocationInfo32) should translate those sizes as needed by "real" DOS apps.

[maxpat78]

@Torinde I made a newer commit https://github.com/maxpat78/dosbox-x/tree/cmd_dir_patch with artifacts to allow -freesize X with X>2048.
Can you test them, extensively and intensively?
Since I changed some uint_t* types, I would be certain that no side effects are introduced.

[Torinde]

Thanks, @maxpat78, I'll test it (but not immediately) and report back.