feat: custom wiki usage block

[polleuretan]

This PR introduces a new feature that allows users to provide a custom "Usage" section for the generated wiki documentation.
Currently, the usage instructions are hardcoded, which limits customisation. This change adds a new wiki-usage-template input to the action.yml, enabling users to define their own usage block as a raw string.

This enhancement provides greater flexibility, allowing teams to include organization-specific examples, provider configurations, or any other custom content they require in their module documentation.

Example Usage

- name: Terraform Module Releaser
   uses: techpivot/terraform-module-releaser@v1
   with:
     # ... other inputs
     wiki-usage-template: |
        # My Custom Usage Instructions
        This is a custom usage block.
        You can add any markdown you want here.
        And use variables like {{module_name}}, {{latest_tag}}, {{latest_tag_version_number}},
        {{module_source}} and {{module_name_terraform}}.
        ```hcl
        module "{{module_name_terraform}}" {
          source  = "{{module_source}}?ref={{latest_tag}}"
          version = "{{latest_tag_version_number}}"
          # ...
        }
        ```

[virgofx]

Thank you @polleuretan for this thoughtful contribution! I really appreciate you taking the time to implement this feature - it's a great start and addresses the need for more flexible documentation.

You've identified exactly the right problem: the hardcoded usage instructions are too limiting for teams that need organization-specific examples or custom content. Your implementation with the wiki-custom-usage-string input is clean and straightforward.

However, I've been thinking about this in the context of issue #184, and I believe we might want to solve this in a more comprehensive way. The challenge with the current approach here is that:

• The custom message is global for all terraform modules
• There's no dynamic component - you can't reference things like the current source path (source = "...") in your custom documentation
• It doesn't scale well if teams want to create more sophisticated wiki content

My thinking is to move this logic outside of the action configuration entirely and instead pull documentation directly from each module's README.md. This would allow for much more powerful and flexible wiki generation.
The idea would be to use non-visual delimiters in the module's README, something like:

<!-- TERRAFORM-MODULE-RELEASER-WIKI-TEMPLATE

## Custom Module Usage

Custom text with dynamic replacements possible.

```hcl
module "my_module" {
  source = "{{MODULE_SOURCE}}"
  # Custom examples here
}
```
-->

This approach would:

• Keep documentation with the module code itself (Allowing for proper markdown formatting in a README.md
• Allow WIKI specific template documentation while not being impacting (being visible in) the main README.md
• Allow for dynamic replacements (like {{MODULE_SOURCE}})
• Enable much richer documentation possibilities
• Scale better across multiple modules

I'm leaning pretty heavily towards moving that route to provide utmost flexibility here. Curious as to your thoughts

[polleuretan]

@virgofx thanks for calling out that the current implementation isn’t flexible enough—and for laying out such a thoughtful, comprehensive alternative.

I’d like to propose a slightly different approach that keeps things simple while still giving us the dynamic power we need:
Accept a template string (instead of a raw string) in the action input and allow users to embed placeholders that get replaced at runtime with actual values
The placeholders could be for example:

• {{module_name}} – the path/name of the module (e.g., aws/vpc)
• {{latest_tag}} – the complete, most recent tag (e.g., aws/vpc/v1.2.3)
• {{latest_tag_version}} – just the version portion (e.g., 1.2.3, without the v)

In our monorepo scenario, we’ll have dozens of modules that all share the same usage‐block pattern. By using this templating mechanism we can define the template once in our workflow configuration and have it apply consistently across all modules.

Please let me know what you think so I can proceed with polishing the new approach.

[virgofx]

The feedback makes perfect sense! I agree we should apply the templating approach globally and then add the more powerful README.md-based dynamic usage separately in the future.

Let's proceed with the current implementation but make these refinements:

• Move the default template from constants into action.yml as the default value (This serves dual purpose - not only for clarity, but can be used a reference also)
• Rename wiki-custom-usage-template → wiki-usage-template (since we're just going to define it here. Not really custom, it's just the actual usage, we happen to define a reasonable default so out of box works decent)
• Update replacement variables for consistency and completeness:
• latest_tag_version → latest_tag_version_number
• Add module_source (And reference this in the default template)
• Add module_name_terraform = ${terraformModule.name.replace(/[^a-zA-Z0-9]/g, '_').toLowerCase()}
• Let's update top-level README.md with proper name references (from changes above) and then maybe a small tiny section on the input configuration for these just before the Example Usage with Inputs section. So it's in the input configuration. You can see how we referenced the note for the more complicated filtering input params. Let's do something similar. So the discussion is in a tiny section with all dynamic replacements documented and explained.

I believe those 5 replacements now should cover a good amount.

I believe this gives us a solid foundation that works well for monorepos with consistent patterns for replacements keeping it fairly dynamic, while keeping the door open for the fully customized per-Terraform Root README.md as an override approach later. Effectively, just parameterizing the hard coded usage now to make it dynamic.

[polleuretan]

👋 @virgofx, I've implemented the refinements you mentioned above.
Please take a look when you have a moment.

[virgofx]

Hi @polleuretan - Sorry for the delay, busy week here. Taking a look and will review!

[virgofx]

Thanks @polleuretan - Going to test a few more things off of main and then cut a new release soon with these changes and some other big ones.