A downside of this structure is that it is difficult to do focused work on the Gradle UI.

## Decision

Introduce a "UI" architecture module to the core platform, and move the user interaction services to this new module.

This includes:

- Logging and progress services.
- Problem generation services (aka the "problems API").
- User prompting services.
- Build options infrastructure.

Prefer either:
  * Provide only non-nullable version and move the `null` check to the call site (if the number of nullable callsites is low).
  * Provide two overloads with a different names (as Java doesn't support overloading on nullability). See