Terms affected by `gw.cutoff` should raise an immediate error if they are ever passed a network that exceeds it.

[krivit]

For dense networks, they silently return incorrect results that may be mysterious to some users (#484).

It should be reasonably safe to simply have the relevant c_ functions return an error, suggesting to the user that gw.cutoff needs to be raised. The *sp, d*sp, and degree C implementations could be instrumented with an option to trigger an error if the network has a shared partner count that is not in the list, and terms that use gw.cutoff could enable that option.

In terms of possible ways to implement this, it may be possible to take advantage of the fact that all degree frequencies add up to the network size, all ESP frequencies to the number of edges, etc., though we would also need to keep track of isolate counts and ESP(0) counts, respectively.

[krivit]

As a further note to self, it may be a good idea to have GW-optimised versions of degree, shared partner, etc., C implementations, that take one argument (maximum value) and compute a vector from 1 to that maximum value.

They could then very easily trap any instances in which an observed or proposed network has a statistic exceeding that value. They are also likely to be somewhat faster, since they don't need to iterate through degree/SP/etc. values but simply map the calculated value onto an array element.