perf: Optimize and reduce size of StringDiffOpKind enum

[neoncitylights]

• StringDiffOpKind::Delete holds a char, but this isn't needed. We only need to know at what position something should be deleted, regardless of what exists at that position.
• StringDiffOpKind::Transpose holds two usize integers but on reflection, doesn't need to hold any (if we're only detecting adjacent transpositions, which means the two letters have to be right next to each other). For example, the Damerau-Levenshtein distance algorithm builds on top of the Levenshtein distance by recognizing transpositions too, but only if they're adjacent.

Ultimately, the StringDiffOpKind enum should look like:

pub enum StringDiffOpKind {
   Substitute(char, char),
   Insert(char),
   Delete,
   Transpose,
}

This allows for two nice optimizations:

• previously, the total size of StringDiffOpKind was 24 bytes. Now, by reducing unnecessary associated data, it's 8 bytes -> this allows for some memory alignment since it'll take a shorter time to copy on the stack.
• The size of a StringDiffOp also reduces from 32 bytes to 16 bytes.

You can test this by calling std::mem::size_of(), with an online Rust playground link to try it out.

fn main() {
    println!("{}", std::mem::size_of::<StringDiffOpKind>());
    println!("{}", std::mem::size_of::<StringDiffOp>());
}

Some nice resources:

• https://adeschamps.github.io/enum-size
• https://fasterthanli.me/articles/peeking-inside-a-rust-enum (long but useful read)
• https://stackoverflow.com/questions/27324821/why-does-an-enum-require-extra-memory-size
• https://stackoverflow.com/questions/1082311/why-should-a-net-struct-be-less-than-16-bytes

[notalfredo]

This looks really good. Like you mentioned when I was implementing the deletion match I noticed that the char field for deletion was probably not needed. Overall this looks really good.

[neoncitylights]

Thanks! Do you want to work on this? I can work on this instead as well.