Squashing v0.9 branch

[kornelski]

@ripytide The v0.9 branch deleting and re-adding v0.8 code throws away git history (git blame) for these files. Also the v0.9 branch does zig-zags with redesigns and renames. I'm thinking about squashing it all to a couple of commits.

Also some renames:

• Gray.v seems to be the best after all. v for value is neutral, avoids specificity of Luma, and readability of .l vs .1. I've figured out that renaming the struct at the point of definition, and exporting under a different pub use name makes nicer error messages Gray_v08 vs Gray_v09, so renaming of the struct across versions is not necessary.

• Maybe HomPixel could be renamed to just Pixel? I suspect most users won't care about the heterogeneous case, and that will be a more straightforward name.

[ripytide]

I'm happy with squashing the commits as much as you'd like since I very rarely ever look at git history personally.

I'm happy with Gray.v. What do you mean by renaming the Gray struct at the point of definition and then re-exporting it and renaming it across versions not being necessary (nevermind I see now in main)?

I'm happy with HomPixel becoming Pixel. I thought about it when first naming {Hom,Het}Pixel traits but I defaulted to being more descriptive, on the other hand I think this would be really useful if/when integrating with the image and imageproc crates since it is the same name as their current Pixel trait which would reduce the amount code churn during a migration.

[ripytide]

Oh I see now in the main branch about the Gray_v08 and the Gray_v09 structs. Yeah that seems better if it makes rustc give clearer error messages. I hope we can eventually remove the old Gray type once the ecosystem has migrated, although I don't know how long that will take.

I see you've made changes to the main branch, are we just using main to make the final v0.8 release and then switching main with the v0.9 branch to the make the first v0.9 release?