Fix stack-buffer-overflow errors in Tetgen found by address sanitizer

To continue the discussion from #395, the output from address
sanitizer under GCC 4.8.3 was actually somewhat helpful.  The relevant
parts were:

```
==48051== ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff55c2eec0 at pc 0x10df1e262 bp 0x7fff55c2eb60 sp 0x7fff55c2eb58
READ of size 8 at 0x7fff55c2eec0 thread T0
...
Address 0x7fff55c2eec0 is located at offset 384 in frame <orient3dadapt> of T0's stack:
  This frame has 21 object(s):
    [32, 64) 'bc'
    [96, 128) 'ca'
    [160, 192) 'ab'
    [224, 256) 'at_b'
    [288, 320) 'at_c'
    [352, 384) 'bt_c'
    [416, 448) 'bt_a'
    [480, 512) 'ct_a'
    [544, 576) 'ct_b'
    [608, 640) 'u'
    [672, 736) 'adet'
    [768, 832) 'bdet'
    [864, 928) 'cdet'
    [960, 1024) 'bct'
    [1056, 1120) 'cat'
    [1152, 1216) 'abt'
    [1248, 1344) 'v'
    [1376, 1504) 'abdet'
    [1536, 1664) 'w'
    [1696, 3232) 'fin1'
    [3264, 4800) 'fin2'
```

The offset listed (384) corresponds to the variable 'bt_c' on the
stack.  So it was a matter of tracking down invalid accesses into this
array (which turned out to occur in a different function) using
standard debugging techniques, but the output from address sanitizer
definitely helped pinpoint the problem.

This particular example is also of interest because valgrind's
memcheck tool apparently doesn't do bounds checking on stack
variables.  From their website:

```
Unfortunately, Memcheck doesn't do bounds checking on global or stack
arrays. We'd like to, but it's just not possible to do in a reasonable
way that fits with how Memcheck works. Sorry.

However, the experimental tool SGcheck can detect errors like
this. Run Valgrind with the --tool=exp-sgcheck option to try it, but
be aware that it is not as robust as Memcheck.
```

I tried this experimental tool, though, and it didn't catch this
particular error.