Document design decision for module design

[MariusStorhaug]

Description

We have arbitrarily said that we have chosen to "stay close to Azure Resource Reference" without really defining what we mean by this. We should have a wiki page under module design or so where we declare the module design decision we have made for general module development.

### Tasks
- [ ] [Wiki module design] Elaborate on why we add optional features such as rbac and diagnostic settings
- [ ] [Wiki module design] ARR alignment - Documentation link in readme
- [ ] [Wiki module design] ARR alignment - Folder structure alignment
- [ ] Azure/bicep-registry-modules#2509
- [ ] [Wiki module design] General design principles - Resource names in main Bicep template
- [ ] [Wiki module design] Test cases - detail why we are using resources instead of modules when deploying dependencies

[rahalan]

@MariusStorhaug and @arnoldna please elaborate and add examples

[rahalan]

-> acceptance criteria for a new module

[rahalan]

@MariusStorhaug and @arnoldna please elaborate and add examples

[AlexanderSehr]

Related to #1180

[MariusStorhaug]

From a discussion with Nate: We looked at the wiki section for Module design - Guidelines we see that we should add the reference to ARR thought we should also mention that we drive for consistancy accross modules, i.e. parameter naming like name, workspaceID etc.

We need help to find more places in the code where we drive for consistency rather than sticking with the Azure Resource Reference. Could we spend some time on our "other topics" calls to brainstorm?