DRAFT: app: add voting pillar; expose hooks and components into packages

[MSzalowski]

Do not treat this PR as the complete work. It just briefly summarizes the idea by the initial implementation

Description

That is just the draft that (maybe) references the idea behind compositing the pillars for the GovTool applications.

Reference

This draft is based on the Roadmap example.

Changes

Behind all of these number of changes crucial files for the idea review are the package.jsons in every exposed package.

This PR introduces GovTool monorepo structure changes which are:

• govtool/frontend -> has been renamed to govtool/wrapper
• Name of the app in govtool/wrapper package.json has been updated to @govtool/wrapper (ref)
• Voting pillar is now exported as a separate package named @govtool/voting (ref) and is imported into @govtool/wrapper via npm package dependency (ref)
• Usage of the exported voting pillars elements can be seen here and here

It is worth the investigation and decision whether (if this approach is acceptable) we want to export complete pages or Pages should be the wrapper for just the logic behind (as it is shown on the roadmap example).
Also - if this approach is to be accepted it is worth mentioning that most likely we should depend on the suspense functionality for integrating such modules/sub-apps instead of just static import. (docs).

Tooling and modules bundling

What approach do we want to follow to wrap app the modules eg.: module-federation, iframes, some server side if the wrapper is not to be handled by current govtool

Additional notes:

• Every @govtool/* package is to be published to some either private or public npm registry meaning that absolute paths to the packages will not be needed and only proper versions are to be submitted in the final sub-application.
• @govtool/components package is most likely to be removed in favor of @mui/material

[Ryun1]

👏 great first step, looking forward to seeing it develop