Go: Add tests for model inheritance and fix bug in promoted methods

[owen-mc]

These tests show several things:

1. That the subtypes column of MaD has no effect for non-interface methods.
2. That the common use of getACall() in QL models is overly broad: see from the ql_S1 comments that by modeling S1 we also match calls to I1, which is an interface that S1 implements. This is not what users would expect.
3. Models for promoted methods act as if they are actually models for the method on the type that it was originally defined on. This is not what users would expect.

This PR also fixes a bug where methods of an embedded field were promoted when they shouldn't have been (because the type already has a method of that name).

[smowton]

Interesting to note that with subtypes = false we actually do model a struct that embeds I1 here. I think we shouldn't (not to fix here, a note for the future)

[smowton]

(Probably good to note these in the corresponding QL files in the manner we would with $ MISSING and similar if this was an inline-expectations test): I believe these are all good results except for the cases that shadow the relevant methods which are FPs.

[smowton]

Again noting expectations to cross-check: I think the embedding result is unexpected

[smowton]

And these are all good except for the overriding cases which are FPs

[smowton]

Similar to I1, the embedding result is bad

[smowton]

Currently subtypes = true for a non-interface does nothing; if it did anything in the future it would be to include embeddings, which we do here by accident

[smowton]

I suggest one more case to include: interface-in-interface embedding, which is a slightly different beast to X-in-struct embedding, where X may be an interface or a struct, since it doesn't create a field

[owen-mc]

@smowton I've revamped the tests to be inline expectations tests. It's just so much easier to deal with. I've added the case you suggested. I've fixed a bug that was causing us to promote methods that shouldn't have been promoted because the receiver type already has a method with the same name. Even with this bug fixed, I agree that the current behaviour of our MaD tests around promoted methods should be changed. The model for IEmbedI1 should not cause us to model methods on I1 - if the user wants that then they can just model I1 in the first place. I will look into this as a follow-up.

[smowton]

Suggest change the PR title and description before merging, and add a change note, since it now actually fixes a bug.

[smowton]

Recommend using the SPURIOUS attribute throughout (and if applicable MISSING, though I don't think there are any missing results) to identify what ought to be fixed

[owen-mc]

DCA with the normal source suite didn't show any changes. I also ran it with the suite @smowton made recently of repos which exercise our models more (which is much larger at 129 repos). This showed alert losses in 7 repos. I looked into them. They almost all seem to relate to getACall being too broad (a known problem which we plan to fix). Most of them were logging queries. So I am happy to accept these alert losses.

[smowton]

I think the spurious annotations are correct, though it's hard to be 100% certain. Once the fixes start to roll in it'll become clear if we see anything other than the expected spurious -> absent transitions.