Allow to have multiple eradius clients bound to different interfaces

[surik]

Right now, we only can have a client attached to one interface. See https://github.com/travelping/eradius/blob/master/src/eradius_client.erl#L269

It would be really useful (f.e. in case of router or proxy) to have an ability to setup bunch of clients with own configuration.

[RoadRunnr]

This is actually a symptom of much larger issue.

eradius was originally a standalone RADIUS server. Many of changes we have made to it have pushed it more into the direction of being a RADIUS library. I think we approaching the point where we should a complete refactor, drop everything that makes it a standalone server/client/proxy and make it into a library that can be used to implement a RADIUS function (client/server/proxy).

It's API should be similar to the diameter app.

Without the standalone functionality, the need of configuration of eradius through the application environment goes away. Everything that is needed to use a RADIUS function will be passed into the application as parameters and options.

[surik]

@RoadRunnr we need a roadmap ;) Something like:

1. Draft the client and server API.
2. Add ability to configure radius servers via API without application environments
3. Allow having multiple eradius clients bound to different interfaces (according to the drafted API)
   ....

[vkatsuba]

@RoadRunnr, @0xAX, @fholzhauser what if we will try split eradius:

• eradius - library
• eradius_prometheus_collector - implementation of server application based on library
• eradius_server - implementation of server application based on library
• eradius_client - implementation of client application based on library
  this way we can try to save all the work that was done in the current application and divide it into separate applications and a library. Also for backward compatibility we can keep the version 2.X.X with support and the new implementation will start from version 3.X.X where we can start use maps as described Add decode_format to allow incoming messages to be decoded into maps #111 etc.