RFC: making a rsp hle library

NOTE: I made this "dummy" PR to initiate the discussion on a possible separation of the rsp hle core into its own library. I will update it depending on the provided feedback.

Context
----------

Recent refactorings of the rsp hle plugin have brought us some nice things:
- decoupling of the m64p specificities from the hle core part (ie {plugin.c, rsp_api_export.ver} vs the rest)
- hle core is almost independant of any m64p dependancies (the only coupling I know is M64P_BIG_ENDIAN in memory.h)
- there is no more any global variables in the hle core (all are in the plugin.c file)
- external users of the hle core can customize certain aspects by defining functions from hle_external.h

These changes paved the way for external usage of the rsp hle outside of mupen64plus based emulator.
See for instance, kode54/lazyusf [1] which is a library which can play usf/miniusf files.
I tried myself to implement a simple regression testing program derived from the core hle [2]

Proposition
--------------

To encourage further external usage (and allow therefore wider testing, and eventually more creative uses) we could make a library out of the hle core part, and make the mupen64plus plugin a mere user of this library. I'll call it librsphle for the rest of the message (but the name is open to suggestions).

Wishlist for librsphle:
- make it as independant as possible from m64p to not force unwanted dependencies on external users
- add some (unit/regression) tests to that library
- add some documentation / readme
- play better to avoid name clashes with external users (ideal case: only export symbols that are needed, and have them prefixed to avoid name clashes)
- __have a stable and simple interface__
- move it to a separate repository ? (but obviously still under mupen64plus organization)

=> to summarize make it a good library that people will want to use [and maybe contribute to ?]

For the record, CEN64 emulator [3] is using this approach to isolate the various components without compromising performances.

Issues
--------

- How to handle the eventual repository split ? (I'm not a git{,hub} expert)
- How to update the Makefile / msvc sln files ?


Conclusion
--------------

While it requires some amount of work, I think this is worth it because of the __bigger usage/testing__ opportunities:
For instance, both kode54 and twinaphex provided good bug reports and allowed to fix to bugs I introduced while refactoring, and even some that have existed before (see issue 596).

Please discuss.

[1]: https://bitbucket.org/kode54/lazyusf
[2]: https://github.com/bsmiles32/mupen64plus-rsp-hle/tree/regtest_draft
[3]: https://github.com/tj90241/cen64

cc: @richard42, @ecsv, @kode54, @twinaphex, @mupen64plus-ae