Let the API free fly(+ sync execution ability)

release more limited, and make more possible for others. the async is very perfect for slow IO operations, such as file or network.  more and more database use memory to cache data. the get operation is not a slow IO, so sync is better than async here. And maybe some database changes the put etc operations more effective. so
why need to limit the async only? on my leveldb's test(add the sync ability to leveldown), only iteractor.next using callback is better than sync. All others are sync better than async. btw, the asBuffer is performance killer.

```shell
          put :    27,334 w/s in    439ms
      putSync :    72,289 w/s in    166ms
      putSync :    72,289 w/s in    166ms        (directly)

        batch :   104,347 w/s in    115ms
    batchSync :   151,898 w/s in     79ms
    batchSync :   144,578 w/s in     83ms        (directly)

          get :    30,769 r/s in    390ms        (asBuffer)
          get :    48,780 r/s in    246ms
      getSync :    76,433 r/s in    157ms        (asBuffer)
      getSync :   240,000 r/s in     50ms
      getSync :   235,294 r/s in     51ms        (directly)

     iterator :    79,470 r/s in    151ms        (asBuffer)
     iterator :   127,659 r/s in     94ms
     iterator :   300,000 r/s in     40ms        (directly)
 iteratorSync :   272,727 r/s in     44ms        (directly)
```

+ [feature] New Sync API methods supported, and you can implement these sync methods to build your level-database package. if no async methods exists, using the sync methods to simulate the async.
+ [feature] the API will be sync if no callback argument.

``` js
var result = open(); //sync call  =openSync
open(function(){}); //async call
```

you only need to implement these sync methods:
```js
_openSync, _getSync, _putSync, _delSync, _batchSync, _closeSync
```

of cause, u can implement these async methods too, suggestion for slow IO functions:

```js
_put, _del, _batch, _close, _next
```