Rewrite `sync-request` subsystem

Changes to `nrepl-send-sync-request`:

   - returned response is in a standard nREPL form (:done and :value were confusing)
   - returned response is a merged dictionary of all the key-vals received so far (not just of "value", "out" and "err" keys as it was before).
   - nrepl-operation is now checked inside this function
   - when only "value" slot is requested, `err` and `out` are meaningfully handled

Other changes:

   - Reduce redundancy in eval APIs by removing several eval functions on CIDER
     side. They were either not used or could be replaced with direct calls to
     nrepl API.
   - Enforce `cider-sync-request:MILDLEWARE` convention and move all requests
     into `cider-client.el`.

-----

After grouping all requests together some question marks emerged.

-  Not all requests send the "session" argument. It still works but I assume it's an oversight. I didn't change that.  
- `macroexpand` op is special as it's imlemented as 3 separate ops "macroexpand" "macroexpand-1" "macroexpand-all". I think this is confusing. It should be one middleware with "expander" parameter.
- All requests are using `current-session`, shouldn't they be using `tooling-session` instead? Otherwise tooling session is not much used. I wonder if it could be dispensed with altogether.


>>> Bozhidar Batsov on Mon, 15 Sep 2014 12:49:39 -0700 wrote:

> We should not assume responses have a result slot, as they actually shouldn't.
> Each request can produce a response with multiple slots of interest.

This is why the additional layer of abstraction that I have added is a
good thing. People will be using `cider-sync-request:info` and won't
care about the internal implementation or how many slots it returns or
the names of it. All these details are encapsulated within
`cider-sync-request:info`.

I am not removing abstractions, I am adding them!

We are really talking about the same thing. I think the source of the
confusion is the name.

The name might sound too internal but it keeps the link to the
middleware and middleware provides a very good taxonomy of the available
functionality. The name also parallels the naming in `nrepl-client.el`
for the core middleware requests.

Alternatively it could be `cider-middlware:info`. Any other ideas?