Add eventing to test builder.

[mitchdenny]

Description

We missed this. It was added to the test builder we use for our internal tests, but not the public API that we ship. Quick fix.

Fixes #6681

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No (not required)
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No
• Does the change require an update in our Aspire docs?
  • Yes
    • Is this introducing a breaking change?
      • Yes
        • Link to aspire-docs issue (please use this breaking-change template):
      • No
        • Link to aspire-docs issue (please use this doc-idea template):
  • No

Microsoft Reviewers: Open in CodeFlow

[DamianEdwards]

@mitchdenny should we think about adding a test that verifies that members added to DistributedApplicationBuilder are exposed on the test builder? I imagine something that will fail whenever a new member is added that then requires either updating the test builder to expose it, or updating the test to explicitly confirm that we don't want to expose it.

[mitchdenny]

Or we could look at making the test builder derive?

[DamianEdwards]

Would be a bigger (breaking?) change to change inheritance wouldn't it? Open to it, just wondering if there's something more pragmatic for the shorter term.