🚀 Feature: Allow Blocks to define their own Options

[JoshuaKGoldberg]

Bug Report Checklist

• I have pulled the latest main branch of the repository.
• I have searched for related issues and found none that matched my issue.

Overview

Right now, all Options for Blocks and Presets are defined on their backing Base. This is good and reasonable for Options that must be provided, like the mandatory owner and repository (#70).

But most or all other Options as are not actually required in practice - at least for create-typescript-app. They're really only required by coincidence if their Blocks happen to be in CTA's "minimal" Preset. Yet all options are being loaded in when any of CTA's Presets are used.

I think in a truly composable architecture, only the Options that are actually used in a production should be factored in. If you, say, omit blockReadme from CTA's "minimal" Preset, I don't think you should be required to provide an options.title.

I don't yet know how this should look. It would be pretty annoying to have to manually redeclare all sorts of options all over the place. I'll want to experiment with having both "Base" Options (the current system) and Block-specific Options.

Additional Info

Marking as status: blocked for the time being. It doesn't block full CTA parity. But I will want it to block a full launch.

💡 ...I wonder if this can be done automatically with some kind of Proxy system? Like, the first time any options.* property access is done, throw an error that indicates to the parent runner that the option needs to be generated?

I actually really like having this be automatically inferred. This way the Options can still be defined in one big area where they can share lazily computed values. 💡

💖