chore: add independent submodules

[craicoverflow]

Closes #160

This PR introduces sub modules to give us the ability to do independent releases. This is important because the individual clients have their own release schedules and keeping them separate means that SDK consumers will only ever get a change when it is released to stage/production.

Verification

Run the examples:

cd internal
go run ./kafkamgmt/kafka_mgmt.go

[craicoverflow]

This allows us to reference local unreleased changes in the examples.

[craicoverflow]

@secondsun @wtrocki I have added an entire section on releasing independent sub modules. Obviously this method has not been executed yet, so we may find some things that do not work when releasing the next time. Worth to have a read.

[wtrocki]

My dream process

1. Each submodule has a changelog (as long as root) that gets created and updated during PR review.
   The developer writes proper change description on SDK. Notes breaking changes etc.
   This way changelog can be extended with additional info rather than relying on gitchlog that is limited
2. Dev does tag when wants to release SDK (releases just stub as every sdk is submodules)
3. Automation check other modules' changelogs and determines what changed.
4. Automation will create individual tag releases for SDK
5. Changelog for each module will be pushed to individual SDK release on github.

Why

1. This way our release process is practically the same and there is the little cost of automating it comparing to manual releases that will take time and will be error prone.

2. No snowflakes - each SDK works the same and it takes 2 minutes to explain how to release them. Quick onboarding.

3. We can employ this strategy across fleet without problem (same bash script will work for sdk-js and sdk-java)

[craicoverflow]

Each submodule has a changelog (as long as root) that gets created and updated during PR review.

Agreed, this is described in the new release process.

The developer writes proper change description on SDK. Notes breaking changes etc.
This way changelog can be extended with additional info rather than relying on gitchlog that is limited

Yes this may be better to do than relying on git-chglog.

2. Dev does tag when wants to release SDK (releases just stub as every sdk is submodules)
3. Automation check other modules' changelogs and determines what changed.
4. Automation will create individual tag releases for SDK

Can you explain this a bit more? Where does the dev do the tag, on the root?

[wtrocki]

Where does the dev do the tag, on the root?

Yes.

1. Create v0.3.0 tag
2. individual module tags are created by automation based on changelogs (changelogs will have different versions)

[craicoverflow]

Where does the dev do the tag, on the root?

Yes.

1. Create v0.3.0 tag
2. individual module tags are created by automation based on changelogs (changelogs will have different versions)

The root module is completely independent from the submodules. Releasing the root will not include any changes from the submodules. If you create a tag for the root module then this means there are no changes in the submodules.

[wtrocki]

The root module is completely independent from the submodules.

Yes. It will be a nonfunctional stub used to aggregate all releases if needed.
If someone needs to release an individual SDK that would be still possible by creating tag.

Btw. This is just suggestion/discussion, not strongly related to the PR we have here.

[wtrocki]

As part of the verification let's create initial releases (despite no new changes are needed)