generate: move configuration to flags

[jacobbednarz]

This updates all the directory and provider configuration that was
previously hardcoded to now be controlled by flags.

Majority of the flags are self explanatory (however I would like some help on
wordsmithing better descriptions) but one that stands out is the difference
between provider-name and rendered-provider-name. Within the code, these
were previously the same value however I have a use case where the provider is
registered as "cloudflare" but we want the documentation to capitalise the "C".
I didn't make it as naive as "just capitalise the provider name" as I know folks
like GitHub who would hate having "Github" 😉 So, provider-name is used
when looking for the binary and schema and rendered-provider-name for when we
are outputting it to the CLI or documentation. If rendered-provider-name is
empty, then we just assume provider-name is fine to output.

Closes #92

[hashicorp-cla]

All committers have signed the CLA.

[dominik-lekse]

Found this helpful for my use case. Had to resolve conflicts with recent main branch.

In case it helps getting this PR merged, you find the rebased version of the PR branch at https://github.com/dominik-lekse/terraform-plugin-docs/tree/config-as-flags

[jacobbednarz]

thanks @dominik-lekse; i've cherry picked your changes into this branch so if we get some eyes on this, we can merge it in. appreciate it.

[jacobbednarz]

@detro i've just confirmed this is still working with the latest patches and merges. is this something i can get on someone's radar for review? if Hashicorp still isn't reviewing changes, that's fine and if that is the case, I'll stop spending my effort on keeping this in sync and just go a full fork instead.

[detro]

Hey @jacobbednarz , sorry for the delay.

I have just taken a quick look and I think I like where this is going. But given the current state of testing in this repo, I might need to manually run some example tests to verify the current behaviour is not broken.

[detro]

So, I think this is looking good. I wish we had time to stop and write some proper regression testing, so that contributions could be more easily handled.

This "parametrization" is very welcome, so thank you for taking the time and the care.

Before we can proceed, could you please add to the CHANGELOG a section for 0.9.0 and a NEW FEATURES entry, describing your work succinctly?

[jacobbednarz]

thanks @detro; I've gone ahead and added the CHANGELOG entry for this change.

totally agree on the testing really lacking here as i had the same issue locally. i didn't end up pursuing it as the testing story in this repository is largely unit test based and this would require more integration in parts which i wasn't sure on the approach we'd like here. happy to go back and retrofit some tests onto that if we have a path forward though.

[detro]

Rebasing this was painful :(

Personal advice: never merge from main, always git fetch origin && git rebase origin/main.

[jacobbednarz]

👏👏👏 thanks for getting this one over the line @detro, you rock!

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.