Switch back to fn()

[mitsuhiko]

Going via FnOnce is not really any better than what we did before. Going to to back to fn() for now. Need to figure out that we're not working with any function pointers that are coming from elsewhere separately.

This now also uses findshlibs to locate in which shared library we're doing all this. The downside obviously is that calls are much more expensive now because we need to enumerate all shared libraries around both sides of the call.

Given what the library is supposed to be used for I believe this is a fair enough restriction.

Fixes #18

[danielhenrymantilla]

Ok, just an idea, which needs to be tested:

What about offering a unsafe + macro-based API for performance?

The macro could force a const eval of the function pointer:

#[macro_export]
macro_rules! bikeshed_name_spawn {(
    $fn_pointer:expr
) => ({
    enum ThisFn {}
    impl $crate::TypeLevelConstFn for ThisFn {
        const FN_POINTER: fn() = $fn_pointer;
    }
    $crate::bikeshed_name_spawn_const_fn::<ThisFn>()
})}

#[doc(hidden)]
pub trait TypeLevelConstFn {
    const FN_POINTER: fn();
}

#[doc(hidden)]
pub fn bikeshed_name_spawn_const_fn::<F : TypeLevelConstFn> ()
{
    // can use F::FN_POINTER
    let _: fn() = F::FN_POINTER;
}

or put another way, having the fn pointer be const-promotable would allow defining our own wrapping function that uses it, which could lead to using name-based function resolution rather than address-based, thus totally bypassing things like ASLR.