Random Number Generator based on AES CTR
First, the obvious advice is not to use this in practice. Rolling your own is fine for learning, but you should use standard primitives when you need actual security. E.g. one from SP 800-90A which poncho linked in comments.

Now, some observations. I haven't read all your code, so I may misunderstand things.



  Is this a good way to whiten the data? Is there a better way?


Looks unnecessarily complex. AES output is already white, unless AES is broken, so you shouldn't need to do any whitening on the output. The massive table which you use for stretching doesn't seem very secure. For example, you are using secret array indices, which may allow for timing attacks.

  Is there an ideal interval at which an AES CTR generator should be reseeded?


A normal AES generator should be reseeded after $2^{48}$ blocks of output at the latest, according to NIST. That number prevents the attacker from having more than a $2^{-32}$ probability of an advantage.


  Is reseeding too often introducing patterns that might be exposed by some form of differential analysis?


If you have a good source of numbers to feed it, you can do it often, but then why not use those numbers directly? (Performance, maybe, in which case you want relatively infrequent reseeding, but much more often than required is possible.)

Seeding with bad input should only hurt if you use an update system that overwrites previous state and can lead to identical key &amp; IV.

  How can this be made stronger? How would you improve upon this? ..and are there any serious flaws in the implementation? 


I would rip out the whitening stage, for the reasons I mention above, and use AES output as the random output. If you want frequent reseeds and don't have access to a fast TRNG, you could leave an SHA-256 loop for updating the AES key.

Alternatively, if security is the objective, decouple the hash based RNG from AES and run them independently, e.g. XORing the outputs.

A couple more things that seem unnecessary: you are XORing two halves of an SHA-256 output together – using one would be as strong unless SHA-256 is broken; you are XORing the AES counter into the IV, when I think you would be better off treating it as a single counter with a longer period.