Add CI trigger back to pipeline generator

[mitchdenny]

Now that we have the majority of Azure SDK pipelines running on the 1ES pools and we have better capacity to scale, this PR adds back the CI triggers so that once a merge is completed that we get a CI run. This will help narrow down build failures in pipelines that occur post merge whereas at the moment it can sometimes take some digging to figure out what particular change introduced a problem.

[weshaggard]

I think this might still be a little premature until we gather more data about our current usages I'd like to avoid enabling these CI triggers yet.

[mitchdenny]

What is the primary concern? Lack of ability to scale, cost, both, or something else?

[weshaggard]

The primary concern is cost vs value. I'd like to make sure we get some good data, both cost as well as usage data over a few months with our new 1ES agents before we turn this on. Once we have this data we will have a clearer picture of how much these new pools are costing for the existing jobs and decide if we think it is worth the cost of enabling the CI triggers.

[mitchdenny]

I think the spend is now pretty well understood (we have a baseline from January, and February is looking to be on-track. There could be a bit of seasonality in there but I wouldn't expect a huge hike unless we change VM sizes/locations. I'll follow-up offline with the data that we already have. Really running the CI jobs post merge just amounts to everyone submitting one more commit to an already open PR.