AST: refactor getLoc() of decls to have a single entry point for all decl kinds, NFC

[nkcsgexi]

After we start to serialize the result of getLoc() in the
.swiftsourceinfo file, getLoc() needs a single entry point to look up via
USRs in the serialized format.

[nkcsgexi]

@swift-ci please smoke test

[nkcsgexi]

@swift-ci Please smoke test Linux platform

[jrose-apple]

This doesn't seem right. swiftsourceinfo still isn't going to be able to provide SourceLocs, which are references into open buffers.

[nkcsgexi]

hmm, that seems to be our plan. When getLoc() is invoked for a module-imported decl, the local source file is lazily loaded and a SourceLoc instance is formed pointing to that buffer.

[jrose-apple]

:-/ I guess you could do that. I was thinking you'd put line/column information in the file rather than offsets, so that it was already in user display form. But I guess LSP wants line/column and offset, so either we record all of it or we need to read the buffer in some way anyway.

[nkcsgexi]

:) One design goal of this is to be entirely transparent to the rest of the compiler pipeline. Plus translating from SourceLoc to line:column isn't so heavy for diagnostic cases

[jrose-apple]

I was thinking being transparent to the rest of the compiler pipeline could mean modifying DiagnosticEngine rather than modifying getLoc. DiagnosticEngine's already where the fake pretty-printed SourceLocs come from.

[nkcsgexi]

We have to channel through getLoc() to be compatible with how merge module works, right?

[jrose-apple]

You have to do something, but whether that means going through getLoc or having your source info serializer call getSourceInfo explicitly is up to you.