docs: naming of modules

[vburckhardt]

Description

Just some small changes in term of naming in example, to make it easier to follow.

Types of changes in this PR

No release required

• Examples or tests (addition or updates of examples or tests)
• Documentation update
• CI-related update (pipeline, etc.)
• Other changes that don't affect Terraform code

Release required

• Bug fix (patch release (x.x.X): Change that fixes an issue and is compatible with earlier versions)
• New feature (minor release (x.X.x): Change that adds functionality and is compatible with earlier versions)
• Breaking change (major release (X.x.x): Change that is likely incompatible with previous versions)

Release notes content

Replace this text with information that users need to know about the bug fixes, features, and breaking changes. This information helps the merger write the commit message that is published in the release notes for the module.

---

Checklist for reviewers

• If relevant, a test for the change is included or updated with this PR.
• If relevant, documentation for the change is included or updated with this PR.

Merge actions for mergers

• Merge by using "Squash and merge".

• Use a relevant conventional commit message that is based on the PR contents and any release notes provided by the PR author.

  The commit message determines whether a new version of the module is needed, and if so, which semver increment to use (major, minor, or patch).

[mounika-nalla]

I think it would be better if we mention the 'optionally' here for the internal IBM rules. Create a first security group with the client security group rules and optionally the internal IBM flows rules.

[mounika-nalla]

Is the default/outputs.tf is deliverately left empty? I would suggest to show the security_group_1.security_group_rule and security_group_2.security_group_rule

[ocofaigh]

@vburckhardt Is this a change we still want to make?