Inconsistencies in filename length determination

In https://github.com/beetbox/beets/pull/5224#discussion_r2054463631, we had a lenghty discussion on a refactoring of filename truncation. Ultimately, the issue is that we don't currently understand the history and necessity of that code very well. It also appears that the current code is not quite right, but maybe in a way that doesn't really matter in most cases.

I'm opening this issue to keep track of some thoughts around this. Some observations and context:
- When `Item.destination(basedir=...)` is used with a non-`None` `basedir`, any `statvfs` calls that are done for path truncation should really check the filesystem at `basedir`, not always the library directory. This has been the case since [the commit](https://github.com/beetbox/beets/commit/d4ddfd1091b2afe7055f33f09a2ba49288924229) that introduced the use of `statvfs` (but the code looks like it might have been unintentional).
- `art_destination` might also be affected (but is probably less likely to generate long file names in the first place).
- With [PEP529](https://peps.python.org/pep-0529/), the Windows fs encoding is utf8, but path truncation should be based on Unicode code points. Thus, our truncation is not really doing what it should, probably shortening paths unnecessarily most of the time. A fix on Windows might be always truncate the Unicode `str` instead of the `bytes` representation. What happens on Linux for FAT/NTFS file systems, though?
- (Some) People care about very long file names: https://github.com/beetbox/beets/issues/3383
- We use the method described [here](https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry) to allow long file names on Windows. Thus, on all platforms [path limits are component length limits](https://github.com/beetbox/beets/pull/1533#issuecomment-129077976).
- Some analysis on length limits on Linux from stackexchange:
- https://unix.stackexchange.com/a/619878/231458
- https://unix.stackexchange.com/a/721355/231458

In summary, how we determine filename length limits, and how truncate names, can probably be improved. It is unclear to me right now how rare situations are where this really matters.

No specific file or test is named. Start by tracing Item.destination, art_destination, statvfs, and the existing filename-truncation logic; compare basedir filesystem handling with Windows and Linux Unicode and byte-length behavior. Done means the applicable path limits and truncation behavior are clearly defined and consistently implemented.

Written by the indexing model from the issue text.