Improve package-sniffing and bind correctly to types in the same package

[benjaminjkraft]

The original motivation here is to fix #283, which is that if you try to use bindings to bind to a type in the same package as the generated code, we generate a self-import, which Go doesn't allow. Fixing that is easy -- the three lines in imports.go -- once you know the package-path of the generated code. (The test that that all fits together is in integration-tests because that was the easiest place to set up the right situation.)

Determining the package-path is not too much harder: you ask go/packages, which we already use for package_bindings. But once we're doing that, and handling errors, it's kinda silly that we ask you to specify the package your generated code will use, because we have that too, usually. So I rewrote that handling too, making package now rarely necessary (see for example the example config), and warning if it looks wrong. This is the changes in config.go, and is the more substantial non-test change. (I also renamed some of the testdata dirs to be valid package-names, to exercise more of that code, or in the case of find-config, just for consistency.)

I have:

• Written a clear PR title and description (above)
• Signed the Khan Academy CLA
• Added tests covering my changes, if applicable (and checked that the test for the bugfix fails without the rest of the changes)
• Included a link to the issue fixed, if applicable
• Included documentation, for new features
• Added an entry two entries to the changelog

[csilvers]

This looks good to me! I like figuring out the package name automatically; that makes a lot of sense to me. Some style comments below but nothing requiring another go-around.

[csilvers]

It seems like this could profitably be later down in the function, maybe lines 166- could be something like:

        packageNameGuess := ""
	if token.IsIdentifier(filepath.Base(pkg.PkgPath)) {
		pkgNameGuess = filepath.Base(pkg.PkgPath)
	} else if token.IsIdentifier(filepath.Base(dir)) {
                pkgNameGuess = filepath.Base(dir)
        }

But I don't really understand if/how that else case could fire. Maybe add some documentation here.

[csilvers]

Yeah, I don't know the semantics of packages.Load, but it seems like Name is empty if the package doesn't exist, but PkgPath is still set in that case?

[csilvers]

Thanks, this comment is very helpful!

[csilvers]

It took me a while to figure out what was going on here, because I'm so used to the Go convention of checking for the error case in the if's, not the success case.

I wonder if there's a way to reorganize this code to keep the current semantics but perhaps adhere more closely to Go convention. Maybe not.

[csilvers]

It's unusual, though I guess not unheard of, for the value of the other return-values to matter when err is not nil. It may be worth emphasizing this in the relevant parts of getPackageNameAndPath, though.

[csilvers]

You may want to comment that this ignores c.Package, and that below you'll check to make sure they're in agreement (or, at least, not in disagreement.)

[csilvers]

"probably cause circular-import issues"?