Use mod real_fn instead of impl real_fn (for cdylib)

[galkinvv]

Change real_fn to be defined in mod instead of impl,
so it is exported while building as cdylib.

This allows building crates using redhook not only as dylib but as cdylib too.
Tested on linux, not on mac (but no mac changes).
For my (simple) use case dylib is 3.6MB while cdylib is 2.1MB.

Actually I don't know any doc details describing why impl function is not exported in cdylib,
but it's looking natural for me (new to rust with c/c++ experience) that "methods" are not exported when building a library with a C-compatible interface, but free functions are exported.

[galkinvv]

TLDR: I want suggest another change, see changest at last link

I'm new to rust, so I'm not sure that the change is for example compatible with older compiler versions, Ive tested only rust 2018 v1.38

By the way I used redhook for a very corner case - hooking the clock_gettime on linux. It was running fine for most apps, but failed with an obscure crash when running rustc itself.

The problem was very obscure: call to dlsym (to get real function) lead to recursive call clock_gettime.
the call sequence of calls was

• clock_gettime(hook)
• real_fn macro
• dlsym (system lib)
• malloc (hooked by rustc execuatbale!)
• clock_gettime(hook)(nested)
• real_fn macro(nested)
• call_once is not ready to nedted usage and preparing waiting which would cause a dead lock, but... calling thread::current() doesn't retun
• thread::current()
• malloc
• clock_gettime(hook)(nested 2)`
• real_fn-call_once-thread::current()-malloc-clock_gettime until a stack overflow

So the top stack near overflow does NOT show that dlsym was a first recursive call initiator!

I developed a code to abort with a clear message in a case of a recursion during dlsym call instead of this complex crash.
Unfortunately it's a bit too hacky to be called "fine-in-production".

galkinvv@b048100

Should I create separate MR for it to discuss details (maybe adding tests, etc) or it is looking too hacky? (I'm discussing it here instead of a separate merge request since code changes are not auto-mergeable)