Set version 0.3.3 && update third-party packages versions && downgrade msys2 && compatibility with now openfhe-development

[ArseniyKholod]

I set new version and also update versions of third-party libraries in ci.yml, I forgot to do it last time

[ArseniyKholod]

As you can observe, now our CI on MacOs fails. In the update of openfhe-development in lbcrypto::Params class all setters were marked as virtual, but destructor was leaved as it was, so non-virtual. It causes a warning and error while compiling with Clang. I opened an issue openfheorg/openfhe-development#825 to understand, whether this non-virtual destructor is desired. This also leads to the same issue with derived lbcrypto::CCParams<...> classes.

So what we can do is:

1. Disable -Werrors, so do not treat warnings as errors if this non-virtual destructor is not desired and openfhe-development will got updated soon with fixing this bug.
2. Find a way around this issue by asking in CxxWrap.jl community.
3. Do not migrate to v1.2.0 before this issue will be solved, if it will be

[sloede]

Thanks for the detailed analysis. What I don't understand though is why you think it's an issue with CxxWrap.jl - to me it seems to be the combination of a newer clang version with OpenFHE.

What about trying to silence the warning for now on macOS by passing -Wno-delete-non-abstract-non-virtual-dtor as a compile argument?

[ArseniyKholod]

Thanks for the detailed analysis. What I don't understand though is why you think it's an issue with CxxWrap.jl - to me it seems to be the combination of a newer clang version with OpenFHE.

What about trying to silence the warning for now on macOS by passing -Wno-delete-non-abstract-non-virtual-dtor as a compile argument?

No, it is of course not an issue with Cxxwrap.jl, but theoretically non-virtual destructor in virtual class is not an error, if no one tries to deallocate the derived class object by the pointer to the virtual class, so there is should be way to wrap normally...

I deleted -Werror and it works, but yes, it is better to disable one particular warning, thanks!

I disabled the warning and it is compiled successfully! I don't think it is a problem of new version of clang, this warning was added not in clang 15, but before, and we already used in previous commits this clang versions, it was ok, I also tested it in #53. But it is always so difficult with compilers...)

Should merge this PR as it is and update Yggdrasil?