Maven assembly of WAR + Docker image

[gsaslis]

What this PR does / why we need it: Largely, this PR includes cherry-picked work from the restcomm1657 branch, where there is an ongoing effort to move from ant to maven for the generation of the WAR artifacts.

On top of that, this PR introduces 2 extra features:

1. a new maven profile which builds a WAR file with JUST restcomm connect + management UI. (i.e. without mediaserver, RVD and WebRTC demo in the same WAR file).
2. the docker image generation of both the "all-in-one" (restcomm/restcomm), as well as the "standalone" (restcomm/connect), ported over from the Restcomm-Docker repository. With this, that repository largely (if not entirely) becomes deprecated and reduces our tech debt.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged): Fixes #2474

Special notes for your reviewer:

1. Please note that due to the cherry picks, this PR also includes the wildfly maven module. I am not sure if you would like that included. If not, I can exclude it, because I presume RC does not fully support wildfly yet (which is the work underway in restcomm1657).
2. At the moment, the Restcomm Media Server has its own docker image and - afaik - so does RVD + WebRTC Demo. This is the reason for the 2 new features above, so we can run each application in its own container, rather than everything-in-one.
3. The generated restcomm/connect docker image has already been tested with the new mediaserver docker image, and we can get a simple +1234 call running correctly. If there is a more extensive list of tests you would like to run, happy to help with that.

[jaimecasero]

@gsaslis i dont think we will be able to merge this into master with all the wildfly10 stuff, specially all the changes in the pom files...

[gsaslis]

@jaimecasero i agree. this is what i tried to highlight on my opening PR comment above. how would you propose we handle the wildfly10 stuff then? Should I just delete that module from this PR ?

i followed this approach primarily so i can cherry pick your commits and you can keep track of what's included.

[jaimecasero]

@gsaslis wildfly10 new module is not really any issue. But along with the new module there were lots of changes to the existing pom files to remove tomcat depends and bring widlfly. Those changes in core project pom files to accomodate wildfly10 qare the ones i would try to exlucude from this PR...

[gsaslis]

@jaimecasero ah, i see, so you're saying i should reverse commit this: https://github.com/RestComm/Restcomm-Connect/pull/2937/commits/a4df2e09a6fc5236ec4b53f111615f23de0dfdc3 ?

[jaimecasero]

@gsaslis that commit a4df2e0 is specially bad as you seen, becuase it introduces wildfly dependencies, and modifies testsuite to run with wildfly.which is still far from supported...

[gsaslis]

@jaimecasero reverse committed with https://github.com/RestComm/Restcomm-Connect/pull/2937/commits/fe1e250f223686ce3d0d56f1fab3c524e489c4e7