bug#1305: All code that currently beeps should use visual bell instead

[Gregory Heytings]

> > AFAICS in other editors error signals are far less frequent (e.g. they 
> > do nothing when you try to move past the beginning or end of the 
> > buffer, or when you press a key binding with no corresponding action, 
> > or when you enter characters in a read-only file, ...), they only 
> > signal "critical" errors.  So I'm not sure it's possible to get 
> > inspired by what they do. What they use are typically popups; I attach 
> > two examples with Visual Studio and Atom, one when a non-readable file 
> > is opened, another when a non-writable file is saved.
>
> This suggests we may want to introduce "levels" of beeping. We generally 
> follow the convention that a command should do *something* so if the 
> command cannot do what the user asked because it is "obviously" 
> non-sensical (e.g. try to move before the beginning or past the end of 
> the buffer, type a key that's not bound, ...) we'd emit a "low-priority" 
> beep, whereas in case of an actual error we'd emit a higher priority 
> beep.  We probably don't need many levels, (e.g. just 2, at most 3 might 
> be enough).

Indeed.  You may have seen that this is what my patch does, except that 
instead of hard-coding the error levels, it lets each user decide which 
errors they want to see with a flashing effect and which errors they want 
to see without flashing effect.