filesystem resize documentation improvements

[calestyo]

Please review.

Further TODO:

• I think it would be valuable to tell people in which steps they can reasonable shrink/enlarge a fs. In some try, where I made the underlying partition on purpose one sector (512B) larger and then tried resize max, btrfs didn't claim that 512B. I’d blindly guess it's one sectorsize as given by btrfs inspect-internal dump-super, what btrfs needs at least? If someone confirms I could make another commit that adds that information.
• For sysadmins which are bad at mental arithmetic, it would be nice if they'd knew, whether btrfs warns/errors if the underlying device is smaller than the size that it wants to use of it? Does it do so, e.g. at mount time, fskc or even while mounted? If so I could add that as well.

[kdave]

There are probably several things that could affect the shrink/grow increments. The minimum is one sectorsize, we had bugs where convert created a filesystem with non-sectorsize aligned size and then allocator complained. There's a round down step to make sure even such converted filesystems work. The same applies for resize. Another alignment is the stripe size that is hardcoded to 64K. The zoned mode uses that as the absolute minimum that would be a valid value for zone size or alignment.

The documentation update looks ok, so PR added to devel, but I guess it can be still improved. The rounding can be detected and at least mentioned when the btrfs command is started, otherwise this is internal to the kernel iplementation and is not logged.

If you have further need for clarification please open a new issue as comments to PRs could get lost. Thanks.