Internal improvement: Fully convert compile-solidity to use TypeScript

[eggplantzzz]

NOTE THAT THIS IS A BREAKING CHANGE FOR @truffle/compile-common.

Note that types were moved from compile-common/src/types.ts to compile-common/src/sources.ts in order to prevent a clobbering issue. src/index.ts is the following:

export * as Shims from "./shims";
export * as Sources from "./sources";
export * as Errors from "./errors";
export * as Compilations from "./compilations";
export * from "./types";

If the type Sources is exported from ./types then it will conflict with the Sources namespace.

[benjamincburns]

Nice work overall - I really love seeing JS code swapped over.

I understand that some of the any types that I flagged might be challenging, so please do feel free to drop a note on any of them that are too challenging to fix now. I think my only ask would be that where that's the case, we should raise issues so that we can improve the types here over time.

Otherwise I think the only thing that I didn't address in my comments is that I think it'd be very nice if the tests were also converted over to TS. Totally not necessary as part of this PR, but I just wanted to give a nudge all the same.

[benjamincburns]

Can these be given a more specific type?

[eggplantzzz]

I changed these to object for now as I'm not certain how accurate I can be about what will be in here to be honest.

[benjamincburns]

If this code doesn't depend on any properties of these (sorry, I didn't go look again to see if it does), then that's maybe fine? Alternatively you could consider typing anything that is opaque to this package as unknown, as that would force a consumer to declare a type for it before actually consuming it.

I'll leave the decision as to whether or not that is appropriate to you, however.

[eggplantzzz]

Do we want to force the user to do that?

[benjamincburns]

I'd vote yes. Using unknown for code that hasn't been typed yet creates a sort of boundary line for unchecked types in our code. If we use any, the unchecked types propagate out far-and-wide, and it can become very difficult to reign it in later.

That said, if there's a difference of opinion here, I'm not staunch enough about this to block the entire changeover to TS just for this one concern.

Here's some reading on the subject, should you want to consider it further.
https://dmitripavlutin.com/typescript-unknown-vs-any/

[benjamincburns]

Oh one other thing - I'd recommend squashing these commits immediately prior to merging (but after review approval). I see at least one update yarn.lock commit, which leads me to believe that there are probably commits added by this PR that don't build properly, and that makes tools like git bisect a lot harder to use.

[eggplantzzz]

Thanks for the review @benjamincburns! Oh, and as for converting the tests to TS, see #5445 where the tests get removed from this package altogether :)

[benjamincburns]

Approved on the assumption that there's consensus that the run function is internal code. If this isn't a correct assumption, please don't merge until that's resolved.

I also left a few comment threads unresolved, but I don't think that resolving them is necessary to get this merged.

Super happy to be seeing more and more of our code converting over to TS!