evaluate inclusive ranges

[Max Bachmann]

A couple of places ranges like the following 0..(end + 1) which can be expressed as 0..=end. This is generally more readable. However I noticed this can lead to larger code gen, since 0..=end has to perform a saturating add, while 0..(end + 1) can use a wrapping add.

This can negatively affect code size. E.g. when updating it in generic_levenshtein_distance I get the following binary sizes:
With 0..(end + 1)

File  .text     Size Crate
5.6%  97.7% 255.5KiB std
0.0%   0.4%     977B strsim
0.0%   0.0%     119B strsim_test
0.0%   0.0%     102B [Unknown]
5.8% 100.0% 261.4KiB .text section size, the file size is 4.4MiB

With 0..=end

File  .text     Size Crate
5.6%  97.5% 255.5KiB std
0.0%   0.6%   1.7KiB strsim
0.0%   0.0%     119B strsim_test
0.0%   0.0%     102B [Unknown]
5.8% 100.0% 262.1KiB .text section size, the file size is 4.4MiB

This should be evaluated on a case by case basis and probably we should add a comment for cases where we keep the old syntax, so this is not rewritten in a future cleanup without rechecking the code gen.