implement AoverIP (OsmoMSC side)

Our standalone OsmoMSC marks the future of the Osmocom core network implementation.So far it does only IuCS (3G). Also add AoverIP to talk to a standalone BSC (OsmoBSC).This is closely related to implementing AoverIP in OsmoBSC.

Improved autoconfiguration of both osmo-msc and osmo-bsc. For osmo-bsc there is now a restriction. Only one MSC can be configured automatically, for more, the user must supply a valid configuration (very rare case anyway)

Improved logging, we now use osmo_sccp_addr_name() instead of osmo_sccp_addr_dump() since _name() displays the pointcodes in human readable form, which is simpler to debug.

The forced reallocation in the MGCP-GW is now configurable via VTY, so we will not break legacy setups with that.

In an ASP application, the default route is now always automatically configured and the VTY command is locked down.

Got a lot of review comments for the osmo-bsc patches. I have worked through all of them, there were some good ideas (cause codes for the error handler, early termination when mgsp_client responds with an error etc...)

Also started to integrate on the automatic ip/interface selection in osmo-mgw. I think it will work out, but only when the CRCX already carries the IP of the receiving entity, which luckily matches our case. In all other cases we must do it the way we already do.

The automatic ip/interface selection seems to work fine. During my normal tests there were no problems with that. Also when testing with NG40 it looks fine. At least the signalling is not the reason why there is no hearable audio.

Tested osmo-bsc under some odd circumstances (mgw down, differen phones etc.) Fixed some bugs/segfaults in the FSM that controls the MGCP.

The FSM that controls the MGW now also supports handover, which means on the bsc side we feature complete from the MGCP point of view. We could now move on and update osmo-msc to the new MGW.

I expressed this probably a bit misleading. Of course it does not generate the packets itself. It just forwards them. The problem here was just that it appended spurious data to the packets making all packets 4k in size.