Refactor the renaming code

[Phlosioneer]

It's now concentrated in the Name struct. Some clones were avoided,
too.

Partly in preparation for #1427

[Phlosioneer]

Oops, forgot to check back for test failures.

[dtolnay]

Thanks! I am closing the PR because it doesn't seem like I will have bandwidth to own the additional surface area of a public serde_derive_internals. It would work better to do this development outside of the Serde repo under a different crate name. Then when the API has settled and there are a variety of use cases implemented against it, we can look at whether it makes sense to bring any of it back into the copy of serde_derive_internals that is used by serde_derive itself.

[Phlosioneer]

Well then... how do you propose to make any progress on #1427? If the API can't be changed, then trying to make room for plugins is pointless; they would have to re-do much of the work in serde_derive_internals, and it raises the barrier of entry extremely high (you need to have a thorough understanding of how proc macros work).

If a tiny refactoring like this is too much, how do you propose to add any way for plugins to operate? This commit adds 7 public functions; all but one is just a getter/setter, and even that one is based entirely on code and functionality that already existed.

[dtolnay]

I am suggesting that someone with more bandwidth should implement a library similar to the functionality of serde_derive_internals, but designed to be used by serde_derive plugins.

Regarding #1427, the invocations would initially look like some variation of:

#[serde_prefix_all = "NetworkResult_"]
#[derive(Deserialize)]
enum NetworkResult {
    Success,
}

which I believe is sufficient for making progress and proving out the model.