Refactor use of asynchronous exceptions

This is a breaking change to the API!

Since we resolved issues #69 and #110, d-p has an exit signalling/handling mechanism much closer to Erlang's than before. Most of the exceptions thrown by d-p are still exported and can therefore be caught and handled however! This is not what we want at all, at least not by my reading of the unified semantics paper. The impression I've walked away with is that links should be uni-directional and cannot be ignored/trapped. I propose that we do not export the linking (and registration) failure exceptions at all, making them impossible to catch without resorting to 'catch-all' which will hopefully put people off. As mentioned in earlier issues (and in the unified semantics paper), if the user wants to respond to the death of another entity then they should be using monitors, not links.

I have already done this (hiding) for ProcessKilledException.

I do not think that terminate should throw a different kind of exception to die - it should throw ProcessExitException with a Terminated type or the string "terminated" or some such. Calling terminate should just be a means for saying "exit now, and I don't care what reason you give".