Feat: use new tree listing

[MarceloRobert]

Changes

• Adds a new page for the treeListing using the new endpoint
• Updates the status type to conform with the 3-status format
• Reorganizes routes and files
• Refactors some component parts to be reusable between treeListings
• Adds a banner to switch between treeListing versions
• Adds a feature flag to switch the main treeListing version
  • Also refactors a lot of components since they now will be able to appear on multiple routes

Logic for the naming of the components/pages/routes:

• we shouldn't have to rename a whole file every time a version changes (such as "treeListing" -> "treeListingV0")
• there shouldn't be a new route for a different version of a page, only a new subroute (note that this is not the same for the backend, where a new version should equate to a new api endpoint for discoverability)
• the latest version of the route shouldn't need to explicit the version
• we should avoid calling things "old" or "new" as these words are relative and may change meaning over time

How to test

Start of with data in the new treeListing table, instructions on how to populate it can be found in #1706
Check the new treeListing page and the old version. Check if the redirects are working as intended

Closes #1559

[gustavobtflores]

LGTM, just a small nit, i'll pre-approve

[gustavobtflores]

and if we have just one route being active at a time, why do we need two different routes? wouldn't be possible to have just /tree and switch behavior with the env flag?

[MarceloRobert]

and if we have just one route being active at a time, why do we need two different routes? wouldn't be possible to have just /tree and switch behavior with the env flag?

The idea is that since changing the feature flag is not on our hands, it is useful to still have both versions up so that we can compare them very easily anytime