feat: wrapper API's using subranges

[chaitanyaprem]

Lot of code duplication as of now, since i had just copied the functions using storage type.
This will be useful to test functionality first.

Will refactor in a separate PR.

[SionoiS]

Can't really review C/C++ code but maybe @NagyZoltanPeter could?

[chaitanyaprem]

Can't really review C/C++ code but maybe @NagyZoltanPeter could?

Will add him.

Anyways, there is nothing special but a lot of copying :)

Once optimizations are done, then i would want thorough review though.

[NagyZoltanPeter]

Can't really review C/C++ code but maybe @NagyZoltanPeter could?

Will add him.

Anyways, there is nothing special but a lot of copying :)

Once optimizations are done, then i would want thorough review though.

Ok, I can review it no problem. I will do it in the evening.

[Ivansete-status]

I'm just adding some comments for now that I hope you find useful :)

[NagyZoltanPeter]

Overall it is working obviously.
I agree to tackle error handling in a separate PR.
In general I'm not a big fan of returning c++ objects as void* and communicate with the lib via them. As soon as we can keep it in-house it can be ok and effective. But given as an open source stuff it is not advisable to use by third parties.
One generic comment: I would not call negentropy_wrapper.c but .cxx/.cpp/.cc but not .c as that one is a c++ source file.
There is a new std::string in the code which should not be heap allocated, stack string is simple ok. (Not changed in this PR).
Error handling would be nice if we define error codes and const error text for the interface.

[chaitanyaprem]

There is a new std::string in the code which should not be heap allocated, stack string is simple ok. (Not changed in this PR).

Thanks for pointing this out! Initially this was an out argument which i later modified to use result. This was remnant which has to be fixed.

[chaitanyaprem]

One generic comment: I would not call negentropy_wrapper.c but .cxx/.cpp/.cc but not .c as that one is a c++ source file.

Agreed. It was named as C file as we were writing a C wrapper for the C++ code but that is anyways addressed in header file via EXTERNC. We can rename it into cpp file.

[chaitanyaprem]

Error handling would be nice if we define error codes and const error text for the interface.

Any suggestions of how to handle it from C to nim?
Many of these functions already return pointer to something, one way is simply wrap the pointer and error into another struct similar to what i did for result. But that doesn't seem very generic approach, if you have any thoughts please suggest.