manage.py sqlall is not truncating long table names for ManyToManyField

(In [10371]) Fixed a whole bunch of small docs typos, errors, and ommissions.

Fixes #8358, #8396, #8724, #9043, #9128, #9247, #9267, #9267, #9375, #9409, #9414, #9416, #9446, #9454, #9464, #9503, #9518, #9533, #9657, #9658, #9683, #9733, #9771, #9835, #9836, #9837, #9897, #9906, #9912, #9945, #9986, #9992, #10055, #10084, #10091, #10145, #10245, #10257, #10309, #10358, #10359, #10424, #10426, #10508, #10531, #10551, #10635, #10637, #10656, #10658, #10690, #10699, #19528.

Thanks to all the respective authors of those tickets.

Actually, the note added to the docs is incorrect, as it was the content it replaced.

Django doesn't set a hard limit of 64 nor 32 characters on the names of the auto-generated m2m intermediary tables, is simply uses the max identifier length (provided by a DatabaseOperations.max_name_length() method) reported by the backend, if any.

The Django MySQL DB backend doesn't define max_name_length() and because of that the ORM machinery doesn't truncate the m2m table name at all. I suspect what the OP was seeing is MySQL showing its 64 chars limitation (a comment in the Django source seems to indicate that MySQL doesn't have a hard limit on the length of identifiers, but rather it only considers the first 64 chars to discern among them, I couldn't confirm this).

In contrast, in the Oracle case the RDBMS identifier hard limit is 30, this is correctly reported by the Django DB backend and so an identifier of length > 30 will get converted to a 30 char identifier composed of the original 26 first chars plus 4 chars of and MD5 hash.

Because of the above, IMHO the current note lacks generality and is a bit misleading even in the case of MySQL.