ci(github): fix type exports in cactus-example-cbdc-bridging-frontend

[ruzell22]

Commit to be reviewed

---

ci(github): fix type exports in cactus-example-cbdc-bridging-frontend

Primary Changes
---------------
1. Removed examples/cactus-example-cbdc-bridging-frontend-*.tgz in ignore paths in get-all-tgz-path.ts file
2. Added main, module, types, and files in package.json

Fixes: #3631

Pull Request Requirements

• Rebased onto upstream/main branch and squashed into single commit to help maintainers review it more efficient and to avoid spaghetti git commit graphs that obfuscate which commit did exactly what change, when and, why.
• Have git sign off at the end of commit message to avoid being marked red. You can add -s flag when using git commit command. You may refer to this link for more information.
• Follow the Commit Linting specification. You may refer to this link for more information.

Character Limit

• Pull Request Title and Commit Subject must not exceed 72 characters (including spaces and special characters).
• Commit Message per line must not exceed 80 characters (including spaces and special characters).

A Must Read for Beginners
For rebasing and squashing, here's a must read guide for beginners.

[ruzell22]

These code changes gives passing custom-checks.

The error changed from "Resolution Failed" to "does not containt type" which other packages encounter as well and is considered "passing"

I tried different methods as well but I was getting more different failing errors such as Internal resolution error, Unexpected module syntax, and not sorted -- which were all failing. I settled with this solution for now since other packages are having that output while passing the attw part of custom-checks.

[petermetz]

@ruzell22 Yeah, unfortunately there is some more work to do on the build scripts of this package before we can fully close this out, BUT what you did for now is OK in my mind to at least appease the linter as long as we keep track of the rest of the work in a separate issue.

Please open a new issue for this and mark it the lowest priority (because this is just an example package).

This way we don't forget that there's something to do here, but at the same time we are not disrupting development of the package itself (I know that @RafaelAPB and team are hard at work on the satp-dev branch)

The issue you open: Please make sure to explain the situation being that the current react build scripts are not at all producing the structure of the ./dist folder that we need and so the task will be about somehow consolidating that into the common directory structure. It might be impossible to do based on constraints introduced by the react build scripts themselves. We probably had this discussion on another issue (with @outSH and @jagpreetsinghsasan) and we concluded there as well that it's just way too much of a hassle for the front end packages to be refactored in a way that complies with the established patterns.
Please also make sure to link to this PR from the issue description that you'll create so that people can get the full picture and the historical discussion.

so, with all those caveats out of the way: LGTM, thank you.