App.geo.ca refactoring for fiscal year 23-24

[bo-lu]

Rationale:

• We are currently on node 14 which is nearing EOL in April 2023. This means we will lose security support if a major vulnerability is discovered past April 2023. Additionally, we do not benefit from improvements and fixes that come with later versions.
• We are currently on a very old fork of GeoView. This means, we do not have the ability to use additional GeoView functions if we continue using this old fork. For example, use case can include: loading map layers directly onto the app.geo.ca map or loading complex geometries on the viewer.
• Our current codebase is not very modular and has many dependencies which may or may not be used. Ideally, we now have a better understanding of which dependencies we want to have and which we can drop (i.e., are some dependencies abandoned? Or are there better alternatives?). Ideally, we will reduce the number of dependencies in the refactor.

Approach:

• We need to partition the code into components. Each component gets its own folder or a dedicated codebase. Each component is kept small and simple.
• Using a components structure, we can create unit tests for each component. Currently, we are not doing so.
• We need a better way to manage the code during the rewrite, with code reviews performed (e.g., at least one review per PR) to ensure the code is clean and well supported.
• To ensure we are not caught for future node releases, we should periodically perform upgrade tests to the latest LTS.

[jvanulde]

@bo-lu note https://github.com/Canadian-Geospatial-Platform/geoview/issues/790

[PVautour]

We have move to efforts to app.geo.ca-v2. We will no longer need to refactor app.geo.ca-v1.