feat: in app click tracking

[Shahroz16]

closes: https://github.com/customerio/issues/issues/8658

Complete each step to get your pull request merged in. Learn more about the workflow this project uses.

• Assign members of your team to review the pull request.
• Wait for pull request status checks to complete. If there are problems, fix them until you see that all status checks are passing.
• Wait until the pull request has been reviewed and approved by a teammate
• After code reviews are approved and you determine this PR is ready to merge, select Squash and Merge button on this screen, leave the title and description to the default values, then merge the PR.

[github-actions]

Pull request title looks good 👍!

If this pull request gets merged, it will cause a new release of the software. Example: If this project's latest release version is 1.0.0. If this pull request gets merged in, the next release of this project will be 1.1.0. This pull request is not a breaking change.

All merged pull requests will eventually get deployed. But some types of pull requests will trigger a deployment (such as features and bug fixes) while some pull requests will wait to get deployed until a later time.

This project uses a special format for pull requests titles. Expand this section to learn more (expand by clicking the ᐅ symbol on the left side of this sentence)...

This project uses a special format for pull requests titles. Don't worry, it's easy!

This pull request title should be in this format:

<type>: short description of change being made

If your pull request introduces breaking changes to the code, use this format:

<type>!: short description of breaking change

where <type> is one of the following:

• feat: - A feature is being added or modified by this pull request. Use this if you made any changes to any of the features of the project.

• fix: - A bug is being fixed by this pull request. Use this if you made any fixes to bugs in the project.

• docs: - This pull request is making documentation changes, only.

• refactor: - A change was made that doesn't fix a bug or add a feature.

• test: - Adds missing tests or fixes broken tests.

• style: - Changes that do not effect the code (whitespace, linting, formatting, semi-colons, etc)

• perf: - Changes improve performance of the code.

• build: - Changes to the build system (maven, npm, gulp, etc)

• ci: - Changes to the CI build system (Travis, GitHub Actions, Circle, etc)

• chore: - Other changes to project that don't modify source code or test files.

• revert: - Reverts a previous commit that was made.

Examples:

feat: edit profile photo
refactor!: remove deprecated v1 endpoints
build: update npm dependencies
style: run formatter 

Need more examples? Want to learn more about this format? Check out the official docs.

Note: If your pull request does multiple things such as adding a feature and makes changes to the CI server and fixes some bugs then you might want to consider splitting this pull request up into multiple smaller pull requests.

[github-actions]

Hey, there @Shahroz16 👋🤖. I'm a bot here to help you.

⚠️ Pull requests into the branch main typically only allows changes with the types: fix. From the pull request title, the type of change this pull request is trying to complete is: feat. ⚠️

This pull request might still be allowed to be merged. However, you might want to consider make this pull request merge into a different branch other then main.

This project uses a special format for pull requests titles. Expand this section to learn more (expand by clicking the ᐅ symbol on the left side of this sentence)...

This project uses a special format for pull requests titles. Don't worry, it's easy!

This pull request title should be in this format:

<type>: short description of change being made

If your pull request introduces breaking changes to the code, use this format:

<type>!: short description of breaking change

where <type> is one of the following:

• feat: - A feature is being added or modified by this pull request. Use this if you made any changes to any of the features of the project.

• fix: - A bug is being fixed by this pull request. Use this if you made any fixes to bugs in the project.

• docs: - This pull request is making documentation changes, only.

• refactor: - A change was made that doesn't fix a bug or add a feature.

• test: - Adds missing tests or fixes broken tests.

• style: - Changes that do not effect the code (whitespace, linting, formatting, semi-colons, etc)

• perf: - Changes improve performance of the code.

• build: - Changes to the build system (maven, npm, gulp, etc)

• ci: - Changes to the CI build system (Travis, GitHub Actions, Circle, etc)

• chore: - Other changes to project that don't modify source code or test files.

• revert: - Reverts a previous commit that was made.

Examples:

feat: edit profile photo
refactor!: remove deprecated v1 endpoints
build: update npm dependencies
style: run formatter 

Need more examples? Want to learn more about this format? Check out the official docs.

Note: If your pull request does multiple things such as adding a feature and makes changes to the CI server and fixes some bugs then you might want to consider splitting this pull request up into multiple smaller pull requests.

[codecov]

Codecov Report

Merging #284 (34a6b5f) into main (303ef55) will increase coverage by 0.22%.
The diff coverage is 80.00%.

❗ Current head 34a6b5f differs from pull request most recent head 82fde24. Consider uploading reports for the commit 82fde24 to get more accurate results

@@            Coverage Diff             @@
##             main     #284      +/-   ##
==========================================
+ Coverage   56.01%   56.24%   +0.22%     
==========================================
  Files         105      105              
  Lines        1180     1177       -3     
==========================================
+ Hits          661      662       +1     
+ Misses        519      515       -4     

Impacted Files	Coverage Δ
Sources/Common/Service/HttpClient.swift	88.88% <ø> (ø)
...ogenerated/AutoDependencyInjection.generated.swift	100.00% <ø> (ø)
...es/Common/autogenerated/AutoLenses.generated.swift	13.15% <ø> (ø)
.../MessagingInApp/MessagingInAppImplementation.swift	78.57% <ø> (ø)
...ogenerated/AutoDependencyInjection.generated.swift	40.00% <ø> (ø)
...gingInApp/autogenerated/AutoLenses.generated.swift	0.00% <ø> (ø)
...ngInApp/autogenerated/AutoMockable.generated.swift	89.18% <ø> (ø)
...ogenerated/AutoDependencyInjection.generated.swift	0.00% <ø> (ø)
...agingPush/autogenerated/AutoLenses.generated.swift	14.28% <ø> (ø)
...ingPush/autogenerated/AutoMockable.generated.swift	0.00% <ø> (ø)
... and 11 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[levibostian]

The comments I have about this PR are identical to the Android PR. I'll approve once those conversations are resolved there and decisions are replicated on this PR.