[llvm] [CI] Upstream premerge terraform configuration (PR #117397)

[Mehdi Amini via llvm-commits]

================
@@ -0,0 +1,31 @@
+# Premerge Infrastructure
+
+This folder contains the terraform configuration files that define the GCP
----------------
joker-eph wrote:

> I've found it very useful to be able to make changes to pre-merge configuration and script, and test them right away as a regular PR to the monorepo.

I probably misunderstand what this PR is doing then, because it seemed to me that nothing here is about something that you would be able to test with a PR, instead it defined the underlying infra (kube, machines, runners) that need to be setup offline before you can rely on it for testing. 

> [...] which leads me to the conclusion that premerge is more tightly coupled to the monorepo.

Sorry: I don't get it, I read this as mixing up unrelated things here, but I may be misunderstanding  what you're doing here. It seems that the two things are 1) the config of the **infra** (machines and runners) and 2) "what is executed by the runner based on some event". 

In the monorepo we have so far: 
1. the cmake config
2. the premerge scripts that define how to invoke cmake & ninja & ... on premerge events.

In Zorg there is:
1. buildbot configs for the machines
2. terraform config for some clusters
3. Docker images for the runners
4. the post merge scripts which define what cmake/ninja/... to invoke on post-merge event.

So it is true that 2 and 4 are at odds (but for good reason, with property such as what @Endilll mentioned above).
But I'm not following why this implies anything about the rest of the config, which is really more "infra" than anything. The question of coupling is really about this: how is the actual kube/docker config more coupled to the execution script (the 2./4. bullet point above that just wraps cmake/ninja basically) in one case than the other?

https://github.com/llvm/llvm-project/pull/117397