Think about plugging potential Data.Tree unfoldTreeM_BF space leak

`unfoldForestM_BF` (both the current implementation and the level-wise one in #198) has a potential space leak. In particular, we need to keep track of the number of children of each node when we dump the child seeds into the queue or concatenate them all. The implementations do this by holding on to the seed lists until it's time to rebuild, and then (one way or another) counting the seeds in each. If the seeds are large, this is potentially a problem. If we want, we can force the seed count earlier, avoiding the leak. However, I haven't yet found a way to do this that doesn't lead to performance problems.