Undo History: do not attempt to display names for since-unloaded layers

...as attempting to retrieve the name will obviously fail.

A better solution would be tracking layer names directly inside the Undo
object itself, but that requires deeper plumbing changes.  I've made a
note to revisit in the future.
Bilateral smoothing (aka "Reduce Noise"): add separable implementation for large performance boost (~20x)

Fixes #138.

First, the good news.

On a 10 megapixel image at max radius (25px), here's the timing for the
new method vs the old method (which is still available via checkbox):

Old (traditional): 302.0 seconds
New (separable): 14.7 seconds

So I've managed to cut processing time to ~5% of its original.  On an 8
megapixel photo at a more reasonable 15px radius, the results are still
pretty drastic:

Old (traditional): 146.9 seconds
New (separable): 9.8 seconds

...or about 7% percent of the original.  The standard separable speed
gain formula roughly applies, e.g. for a P x Q kernel, performance is
improved by PQ/(P + Q) - so for a radius of 25 (which is an actual
kernel of 51x51), the separable function should finish ~25x faster than
a naive convolution.  Our implementation is slightly worse than that,
owing to some unique overhead (which I can hopefully reduce with further
testing), but still, well worth the effort.

Now, the bad news.  (Or should I say, the "meh" news.)

Bilateral smoothing is not technically separable.  The spatial component
is, but the color component is not.  So technically, this a mathematical
no-no.

That said, others have demonstrated that with some clever estimations
and planning, you can approximate a true bilateral convolution pretty
closely.  Pham and Vliet
(http://www.cecs.uci.edu/~papers/icme05/defevent/papers/cr1296.pdf)
studied this in detail in a 2005 paper, and as they discuss, the overall
SNR improvement between a full convolution and a separable one is
surprisingly close, especially for photographs.  The primary difference
is some unavoidable vertical drift on images with sharp diagonal edges.

Also complicating matters is that a number of precautions have to be
taken to get that close approximation, which makes the new method a tad
slower than it might otherwise be.  Because I went with x-y order,
horizontal edges will get better treatment than vertical ones, but the
results are typically difficult to distinguish unless compared
side-by-side.

Because some scientific work might call for proper bilateral smoothing,
I've added this new functionality as a toggle (selected by default).
For most users, the fast mode should be a nice improvement, but for
those who need max accuracy, the old implementation still works just
fine.

As the tool is now capable of real-time previews, even at high radii,
I'm content to close #138.  Further improvements would require an
entirely different implementation (e.g.
http://people.csail.mit.edu/sparis/publi/2006/tr/Paris_06_Fast_Bilateral_Filter_MIT_TR_low-res.pdf),
and I've got bigger fish to fry, so I think it's time to suppress my
obsessive need to optimize everything, and leave this tool behind for
now... ;)