fix: Do not rely on cpath when loading rust library

[dmtrKovalenko]

I faced the problem in fff.nvim which was inspired by blink.cmp in a lot of terms when the codesnap nvim update caused fff to stop loading the binary. Same just happened with blink cmp, it looks like this:

Error executing vim.schedule lua callback: error loading module 'blink_cmp_fuzzy' from file '/Users/neogoose/.local/share/nvim/lazy/codesnap.nvim/lua/libs/mac-aarch64_generator.so':
	dlsym(0x971c25b0, luaopen_blink_cmp_fuzzy): symbol not found
stack traceback:
	[C]: at 0x0100f42314
	[C]: at 0x0100f42710
	[C]: in function 'require'
	...l/share/nvim/lazy/blink.cmp/lua/blink/cmp/fuzzy/init.lua:17: in function 'set_implementation'
	.../.local/share/nvim/lazy/blink.cmp/lua/blink/cmp/init.lua:24: in function ''
	vim/_editor.lua: in function <vim/_editor.lua:0>
13:43:55 msg_showcmd :

This is happening becuase of global relying on cpath is unsafe as it is global and can be modified by anyone, instead I used the pacakgepackage.load_lib with the provided path which fixes the issue completely

[saghen]

Interesting, thanks! What is codesnap.nvim doing to the cpath that causes the failure? I like the cpath solution because it can be modified by anyone, allowing users to specify their own location for the binary, without explicit blink.cmp support.

[dmtrKovalenko]

https://github.com/mistricky/codesnap.nvim/blob/main/lua/codesnap/module.lua#L38-L38 This is what they are doing, the problem that because it can be modified by anyone every plugin that relies on it is unreliable.

I think it is way easier to provide a configuration level option to specify the custom binary location, but it's your call