Allow option of using Memory mapped file(s) instead of direct buffers

Hi,

We are using kryonet for some time now in our project. However, we could not afford to have limited byte buffers for read/write in TCP Connections, as we are sending objects that follow the composite pattern, so object sizes are not fixed and predicable in fact. So we tweaked a bit the code and tried to added ability to overcome this, but we just figured out that we did it wrong in a way and that client server communication is a bottleneck for us, especially when there are two or more clients connected.

So I am trying once again to figure out how to improve our own mistakes and one idea came to my mind and that's: _Why not allowing users to initialize the client and/or server with mapped byte buffers pointing to the memory mapped files, instead of the direct buffers?_

The benefits would be following:
- I can select how big are the mapped files and this is really flexible ( I could easily select 4Gb for example). With direct memory this is not an option.
- Write and read operations should be performant enough (check this blog from Martin - http://mechanical-sympathy.blogspot.rs/2011/12/java-sequential-io-performance.html)
- The implementation does not to change at all, as it's already working with the byte buffer API, so basically we would need only new constructors for switching to mapped byte buffers..

What do you think, did I not consider something here? If you think this is valid option, I have nothing against in providing the pull request, I would just need some agreement on how to implement it.