Improve release process around exported submodules

[evantorrie]

PR #2090 and #2092 have helped in moving the smartagent, timestamp and oracledb receivers/processors/extensions into their own go modules, but there is still extra work to make them readily accessible by external code which wants to integrate them into a custom OpenTelemetry Collector build.

As described in this PR's RELEASING.md explanation, exported go modules need to also be tagged appropriately in the source repo such that go get <module>@v0.61.2 (for example) can fetch them directly from github.com.

The primary changes here are

1. Modify the names of the exported go modules to exactly match their subdirectory paths inside the repo. While this is not a problem within the repo where replace directives are used to point directly to the in-repo source, for external users, the names of the modules should match the names of the subdirectories.
2. Create a release process that creates the correct tags on the repo to allow go get to find the specific submodule within the repo. Specifically, if a module is located inside the pkg/receiver/smartagentreceiver subdirectory, then external sources can only reference a specific version x.y.z of the module if there is also a tag pkg/receiver/smartagentreceiver/vx.y.z on the repo.
3. Finally, to verify that tags have been created correctly after a release, adding an example which will build an OpenTelemetry Collector binary that uses those externally referenced modules without any replaces directives is a good method of validating that the tags are in the correct place.

I've mostly cribbed the release process for this multimodule versioning and tagging by reusing the multimod tool developed for the opentelemetry-go and opentelemetry-collector-contrib repos.

Feel free to change, reuse portions, or discard this PR. There are likely places where I'm not following Splunk standard conventions given I'm an outside contributor.

[atoulme]

Thank you for the PR! We appreciate it and will review asap.

[atoulme]

@evantorrie thank you for taking the time to build this exhaustive PR. We appreciate it.

There are elements of this PR that we should look at integrating right away, such as fixes to paths or package declarations for examples. I will peel them off from this PR into their own PRs, making them easier to distinguish from the main work you performed here. This will allow our engineers to work on reviewing your main body of work, specifically the RELEASING.md file and accompanying artifacts.

[evantorrie]

Closing in favor of #2644 which addresses directory names/module names and a subsequent separate PR to address the tagging/release process.