Reproducible stdlib artifact

[abgruszecki]

This PR reorganises code to make it easier to build an artifact for stdlib.

The idea is to move the project definitions for community build from test sources to normal sources, and to add a main method to community-build project which, for now, allows locally installing the stdlib, but in the future could be extended to installing any project in the community build.

[smarter]

If we're going to change how the community build works, I suggest making our sbt build itself responsible for building/publishing these projects: so for each project in our community build we create a corresponding project in our sbt build (which overrides the compile task to run sbt compile in the project directory, etc). The advantage of doing that is that we can declare dependencies between these sbt projects so things can run in parallel (which is starting to get necessary given how long our community build takes to run), and we don't end up reinventing our own build tool.

[smarter]

(I'm not saying this has to be done now, but I'm getting worried as the community build stuff gets more and more elaborate, so I think it's good to discuss how we want it to evolve)

[smarter]

-Yerased-terms should already be set when -Dscala.build.compileWithDotty is enabled, is that not working for some reason? https://github.com/scala/scala/blob/8c86b7d7136839538cca0ff8fca50f59437564c0/project/DottySupport.scala#L51

[abgruszecki]

I didn't add it for any better reason than it being already set by sbtTestCommand. I guess I can check whether the stdlib compiles w/o this option.

[abgruszecki]

Reg. making community build be defined in SBT: that sounds reasonable, though I'm not certain if we couldn't just define a single task per community project. Either way, I very much have no strong feelings about this; I just want my stdlib artifact.

[sjrd]

If we're going to change how the community build works, I suggest making our sbt build itself responsible for building/publishing these projects: so for each project in our community build we create a corresponding project in our sbt build (which overrides the compile task to run sbt compile in the project directory, etc)

Doing that will mean that your build has a lot more settings, and that it will therefore be a lot slower to load.

[smarter]

Indeed, so one task per project as suggested by alex would be better.

[abgruszecki]

@smarter so can I get an approve on this one so we can merge it?

[smarter]

Sure, did you request a review from me before and I didn't see it?

[abgruszecki]

@smarter oh, I kind of assumed that you wanted to review this since you immediately commented on it. Well, thanks for the review!