Make ComrakExtensionOptions non-exhaustive

[CosmicHorrorDev]

Resolves #303

Note: This is a breaking change, so it will require a breaking semver bump on next release

I would also be willing to add builders for constructing all parts of ComrakOptions which is a bit more ergonomic to construct things with. All intermediate states of constructing ComrakOptions are valid, so they can just be implemented with setters on the structs instead of requiring a separate type

[tgross35]

I am not a maintainer (no connection to the project) but would you maybe consider adding it to all the config structs?

ComrakExtensionOptions
ComrakOptions
ComrakParseOptions
ComrakPlugins
ComrakRenderOptions
ComrakRenderPlugins

If there is to be a one-time breaking change for exhaustiveness, may as well apply it to everything that might want to add options in the future

[kivikakk]

If there is to be a one-time breaking change for exhaustiveness, may as well apply it to everything that might want to add options in the future

I agree. I'll rebase this shortly and add those before I merge.

[kivikakk]

I've decided to leave the top-level Options struct out of this change for now.

[CosmicHorrorDev]

@kivikakk are you fine with me adding builders for the non-exhaustive options to make them less verbose to construct?

[kivikakk]

I'm just rebasing @YJDoc2's #292 now! :)

[CosmicHorrorDev]

Oh I somehow missed that 😅

Thanks for the great library btw!

[tgross35]

Thanks for the great library btw!

Agreed, we apprecaite it!

[kivikakk]

Thanks both, that means a lot! The contributors list is getting longer — thanks for all your help. 😊

[digitalmoksha]

🤔 does this change require an update to the README?

[CosmicHorrorDev]

What part do you think would need a change? I don't see any code examples that use options or plugins aside from passing Options::default()

[digitalmoksha]

Ah you’re right. I was thinking the calling interface was changing.