No malloc bliss

[james-d-mitchell]

The purpose of this PR is to remove the use of malloc in the version of bliss that's vendored by Digraphs. The rationale behind this is the same as in PR #281:

I'm writing some code that involves a very large number of calls to the homomorphism finding code for relatively small digraphs.

Another thing that stands out when profiling this is that the top three or four things in the profile are all related to bliss mallocing and freeing memory. This PR will make it possible for the homomorphism finding code in GAP to modify a bliss graph in-place (without any memory allocation or deallocation), and repeatedly reuse that graph and all of its associated data structures in bliss for finding the automorphism group.

With this PR (in its current unfinished state):

gap> D := CompleteDigraph(2);;
gap> for i in [1 .. 100000] do
> HomomorphismDigraphsFinder(D, D, fail, [], 1, 2, 0, [1, 2],
> [], [[1, 2]], [[1, 2]]);
> od;
gap> time;
660

in the stable-1.0 branch:

gap> D := CompleteDigraph(2);;
gap> for i in [1 .. 100000] do
> HomomorphismDigraphsFinder(D, D, fail, [], 1, 2, 0, [1, 2],
> [], [[1, 2]], [[1, 2]]);
> od;
gap> time;
1205

This PR is work in progress, I'm just pushing now to see what happens with the CI, and to ask for comments.

[james-d-mitchell]

The failing test is the one using the external bliss, which I'd expect because I didn't account for that yet.

[wilfwilson]

Cool.

[james-d-mitchell]

I'm done with this, it's ready for review, I suggest squashing and creating a merge commit when ready.

[ChrisJefferson]

I had a quick glance at this looks reasonable.

I think this would make digraphs behave very badly in HPC-GAP, if someone calculated graphs in multiple threads. For that reason, it might be worth trying to keep support for an external bliss, if it isn't too much pain, just in case HPC-GAP ever gets going/released.

[james-d-mitchell]

Thanks @ChrisJefferson, the homomorphism finder in Digraphs (which is the only part of Digraphs that can take advantage of these changes at present) is already highly non-thread safe, and I don't think this change makes it any worse. It'd be easy enough to make it thread-safe in the future in any case, but I didn't see any reason to do it just yet.