x/tools/internal/refactor/inline: choose better local names for renaming imports

[gavinkflam]

Part of #63352

The current mechanism takes the last segment of the package path and appends a numeric suffix (if needed) to ensure uniqueness. This produces low-quality local names such path2, format3 and strings5.

I propose to add strategies (2) and (3), as illustrated below, to generate better names. These follow common practices for package aliasing and result in more meaningful names.

1. Try PkgName (unchanged).
2. Try PkgName + "pkg". For example, path becomes pathpkg.
3. Prepend preceding path segments until the name is unique or no all segments have been used. For example, golang.org/x/tools/internal/astutil becomes internalastutil, toolsinternalastutil, xtoolsinternalastutil, or golangorgxtoolsinternalastutil. Adding a length limit might be a good idea.
4. Appending a numeric suffix (unchanged). For example, path becomes path1, path2, ...

I'd love to implement these myself.

[gavinkflam]

@adonovan What are your thoughts?

I'd love to implement the new strategies and submit a PR.

[thediveo]

I find the examples you give very hard to read, more so within code. It would work though in several cases I've come across with protobuf-originating packages that are versioned, such as Docker, OTel, ... Not sure if CamelCasing would improve the situation. Also, my example with protobuf packages wouldn't necessarily be handled here and I see too few import clashes to really want help here, especially when there's some chance of getting "internal" as part of it into the game. The repo name might be much more descriptive, but then, what's a repo name and where is it in an arbitrary import path?