Consider splitting the API into client- and server-related parts

[tnull]

Currently, the LSPS0/LSPS1/LSPS2 message handlers implement both 'client-side' and 'server-side' behavior. The corresponding event types therefore also hold all events. This is particularly painful for 'client-side' users that should not to be bothered by most of these events and the corresponding API complexity.

We should seriously consider splitting this up now that our LiquidityManager won't be the central interface for everything but will only allow to access the underlying LSPSX message handlers. Since we modularized the interface in #58, we could now also consider to split LSPS1 and LSPS2 parts into client and server-side objects that can all be held by the LiquidityManager.