Final split between legacy compose and BAN-ID data processing

[antoineludeau]

WARNING : pre-requisite on this other PR : #383

Context

For now, data coming from the new API system (REST API + Postgres + export to Mongo) was going into temporary collections to be able to tests the system with real case scenario.
Now that tests have been done, we need to make the final switch to connect the new system to the current mongo exploited collections.

Enhancement

With this PR, there are the following changes :

• a new route /api/legacy-compose/:codeCommune/ used only by "id-fix". The current route /ban/communes/:codeCommune/compose is now sending a request to "if-fix" ONLY.
• the bal garbage collector has been modified so that it sends the de-synchronized district to "id-fix" instead of asking for a legacy compose.
• a new property "withBanId" has been added to "communes" collection data to be able to differentiate data that comes from the legacy (withBanId=false) and data that comes from the new system (withBanId=true). This property is also used in the legacy compose to not compose a district that would have passed by the new system.
• a new flag "ignoreIdConfig" used in legacy compose to be able to revert a district from the new system to the legacy system (in a case where a district have published its district with BAN-ID and then would like to publish it without them).