fix: Gracefully handle errors when disabling C modules

[Sculas]

This PR makes a small change to mlua so it no longer panics when unable to disable C modules.

This is primarily meant for Pluto, which has sandbox options that fully disable loading C modules, which would otherwise conflict with mlua also trying to disable a loader that no longer exists.

I'm not 100% sure if throwing the error away is the best solution, but it seems extremely unlikely that this would fail in any logical sense besides package.loadlib or the searchers not existing, in which case the end goal was already reached (being unable to load any C modules).

I'm happy to fix this differently if you have any other ideas!

[khvzak]

I'm working on adding Pluto support to next mlua and will check. Are you using a custom Pluto build with some functionality disabled?

[Sculas]

See my comment in my other PR first (https://github.com/mlua-rs/mlua/pull/529#issuecomment-2679615214), compiling with the following flags:

use pluto_build as pluto;

fn main() {
    println!("cargo:rerun-if-changed=build.rs");
    pluto::Build::new()
        .opt_no_binaries()
        .compile();
}

Results in Pluto modifying the searchers table, while mlua tries to do the same (which cannot be disabled unless you use unsafe): https://github.com/mlua-rs/mlua/blob/e706ae4fcb66a1a64cb41ae49ad144be68129191/src/state.rs#L1950-L1958 Please note that Pluto does more than just this when you disable binaries, so "just don't use that option" is not a proper solution.

However, given that Pluto support is being explicitly added to mlua, you can also consider feature-gating this for Pluto. But that includes a side effect where if someone doesn't disable binaries, mlua won't disable C modules anymore, which may also not be what you want. Hence, silently ignoring the error might be the best option here.