Fix #75 by updating TOP method node id and returned overridden methods

[nimakarimipour]

This PR resolves #75 by updating TOP node id and index. Also making sure that getClosestSuperMethod() only returns methodNode for discovered nodes. (Declared in module)

[lazaroclapp]

Looks good to me except for one question:

• Here, in MethodDeclarationTree.addNodeByLine, where does the id come from? Is that from the TSV files? And if so, is that list one-indexed or zero-indexed? Because this change seems like it could cause MethodNode.TOP, which I believe is an artificial node, with the first node in the TSV.

That said, I pulled in this change and managed to get past the crash from before, but I am having a separate issue. Will report on the tracker.

[nimakarimipour]

Looks good to me except for one question:

• Here, in MethodDeclarationTree.addNodeByLine, where does the id come from? Is that from the TSV files? And if so, is that list one-indexed or zero-indexed? Because this change seems like it could cause MethodNode.TOP, which I believe is an artificial node, with the first node in the TSV.

That said, I pulled in this change and managed to get past the crash from before, but I am having a separate issue. Will report on the tracker.

@lazaroclapp The list is one-indexed and the ids come from the tsv file. It is guaranteed that ids starts from 1. Please let me know if you approve this and I will land this. Thank you.

[lazaroclapp]

SGTM!

Edit: For my own clarity, that id originally comes from ScannerContext.getNextMethodId() in the type-annotator-scanner, which starts with a zero id internally, but pre-increments it before returning it every time, so it does count 1-indexed.