Avoid add_constraint symbol conflict.

[kkofler]

include/auxiliary.h (remove_constraint, add_constraint): Use #define to rename these to less generic names (daqp_aux_remove_constraint and daqp_aux_add_constraint), to work around a symbol conflict with other solvers (in particular, with lp_solve).

This is a fun one I had to debug. In my application, I have to solve both LPs and NLPs. For the LPs, I am currently using lp_solve. For the NLPs, I am using SLSQP, and trying DAQP for the QPs in SLSQP.

Unfortunately, lp_solve has a public API symbol called add_constraint, which, as a result, is also exported from the shared library. This is bad, but I doubt I can get lp_solve fixed. As a result, we ended up with a symbol conflict, and (only in that executable linked to both lp_solve and DAQP) DAQP code was calling the lp_solve add_constraint instead of the DAQP one from auxiliary.c. (Unfortunately, the glibc ld.so will just silently resolve all references to a given symbol name to the first symbol with that name that it sees, even when that is clearly not what we want.) Obviously, this caused DAQP to fail.

add_constraint and remove_constraint are really generic names that are just asking for symbol confllicts. My application actually ends up with 3 different add_constraint functions linked in, since there is also one in NLOPT, however the NLOPT one is static to a single C file and as such not visible externally, hence it does not participate in symbol conflicts.

There are 2 things that can be done to prevent this kind of conflicts:

• The symbols for non-API functions could have hidden visibility in DAQP (__attribute__((visibility("hidden"))), or use -fvisibility=hidden and add __attribute__((visibility("default"))) for the symbols that should be exported). Note that this means that DAQP shared libraries no longer export those symbols (those that have hidden rather than default visibility), so those functions cannot be called directly anymore, if that is something you want to support.
• The non-API functions can be renamed to names that are not ambiguous. This pull request selectively does that for only those 2 symbols, and in a somewhat hackish way (e.g., if one includes auxiliary.h from DAQP before lp_solve headers, the #define hack will break).