Improve navapp development setup

In CMS-13512 we improved the ProxyFilter to allow runtime switching between serving from the development server or from the packaged resources (jar files).

This works well for existing frontend apps (channel-manager & projects) but the navapp requires more work as it was not setup to be served over the ProxyFilter during development.

A short recap of the work done that lead to this issue:

To support serving the navapp from a CDN, the location of the navapp is configurable. By default, all navapp resources are served by the ResourceServlet /angular/navapp.

Currently, we use the aforementioned configuration option to also serve the navapp from the development server, which makes sense, but has the shortcoming that it does not support a runtime switch between serving from the development server or from the packaged resources. This can only be achieved if we serve the navapp resources from /angular/navapp in the cargo.dev profile, but that does not work because the navapp development server does not serve the following two files:

• penpal.js
• bloomreach-navapp-communication.umd.js

There is special logic for these files in the backend that ensures they are still served from the ResourceServlet /angular/navapp when the navapp is configured not to be served from /angular/navapp.

A solution for this is to split these two up: serve the navapp resources from /angular/navapp and the navapp-communication resources (penpal.js and bloomreach-navapp-communication.umd.js) from /angular/navapp-communication.
This way we can drop using the CDN configuration option for development purposes and simply leverage the ProxyFilter. This works as expected, no need to change anything in the loader.js.

Although this works as expected, there were concerns raised by Michiel Rop and he proposed a different solution:

Frontend developers have the need to just use one profile ( cargo.dev ) and fallback to the packaged resource if the resource cannot be found. We could specify the brx.navapp.location in the cargo.dev profile and let the loader.js fallback to the cms location (baseTab.href="." ) if the filelist.json cannot be found.