Add secondary stress benchmark for adding trait in owner's trait_map

[aerooneqq]

This PR adds a new secondary benchmark for case when a new trait is added to in_scope_traits_map query. During experiments with queries in #155678 (where I merged some queries into one, meaning invalidation of any part of the query will invalidate whole new merged query) improvements were reported, however I did not find any benchmark that covered case when a new trait is added to in_scope_traits_map query, so I can not fully trust those results.

A real-life scenario where such regression is possible is importing (or creating) a new trait with functions whose names are mentioned frequently in a file in a deferred typecheck context.

cc @petrochenkov

[Kobzol]

Looks simple enough, and should be fast to build. @nnethercote Any concerns?

[petrochenkov]

I think if rust-lang/rust#155678 makes the new benchmark red in the incr-changed scenario, we should still merge it.

Code changes between two incremental builds do not typically include adding a trait (import) with specific item name.
Sure it can happen occasionally, traits are indeed added sometimes, but if 1 out of 100 incremental rebuilds becomes slower that's probably not a big deal.

[nnethercote]

Code changes between two incremental builds do not typically include adding a trait (import) with specific item name. Sure it can happen occasionally, traits are indeed added sometimes, but if 1 out of 100 incremental rebuilds becomes slower that's probably not a big deal.

Yes, adding traits does seem like a rare scenario so I don't feel the need to for a benchmark to test it. I won't block it if someone else is strongly in favour, but it seems fairly low value.

[aerooneqq]

I think if rust-lang/rust#155678 makes the new benchmark red in the incr-changed scenario, we should still merge it.

On my laptop it shows the following numbers (with regressions in incr-patched scenario). But they are not as big as it was in first perf run.