* Travis-CI build & nmake batch file updates

* pypi fix

* Travis-CI build & nmake batch file updates

* pypi publish fix

* Add binary output option (-b) to kstool

Using -b option, kstool will print the encoded instructions to stdout
in binary format.

For example:

```
kstool -b arm64 "CCMP X0, X1, 4, EQ" 0xcafebaba | xxd
00000000: 0400 41fa                                ..A.
```

For `getopt`, this commit reuse the getopt.c from capstone-engine.

* Fix build for MSVC

Some platforms split *.so into -devel, which then requires the python library
to be patched to load libkeystone.so.0 instead of libkeystone.so.

* Travis-CI build & nmake batch file updates

* PyPI packaging

* quick fix for pip and python binding isntall

* better fix

(cherry picked from commit 06afb493e09cb7591fedf17cc5b06f9a865b385c)

When trying to execute `make install` inside the go binding sample, the output shows an error that is specified by guitmz in issue #363 

Adding the missing cgo LDFLAGS resolves this issue.

- A bool coming from C cannot be trusted; functionally it is a c_int,
    and conversion to bool must be done by comparing to 0;

  - similarly, a `#[repr(C)]` enum cannot be trusted to be a `u32`;
    it is more often than not a `c_int`. This could cause breakage with
    the ABI of the C functions of the binding. So the signatures and
    enum definitions have been adapted based on the
    `include/keystone/keystone.h` definitions.

  - and most importantly: a ks_handle is a `ks_engine *` in C parlance,
    and using `size_t` to represent it is not the right way. Moreover,
    so doing prevents the `Sync` and `Send` traits from being
    auto-unimplemented, meaning that this is implicitly asserting that
    keystone is multithread-safe, even for the same instance. If that is
    the case, then a `unsafe impl Sync for Keystone {}` (ditto for
    `Send`) should be added to make such assertion explicit.

    That's why an opaque type using the classic Rust idiom of a
    zero_sized #[repr(C)] struct has been made (while waiting for Rust
    to feature external types), and `Option<ptr::NonNull<_>>` is being
    used as the pointer type (equivalent to *mut _), but it allows to
    communicate nullable / non-nullable invariants at the type-level.
    This has then been transposed to the internals of keystone-rs.

Bug fix for win32 jna access

* Fix Rust bindings

* Various small improvements for the Rust bindings

* Remove unused dependencies

* Use the cmake crate to compile keystone

* Add Windows support to Rust bindings

* Cleanup doc a bit

* Fix symlink path

* Link to C++ standard library

* Build all keystone targets