Thanks for the fix!

@Tyriar I suggest to rethink the way we handle the bell for xterm.js v5. Idea:

• Strip sound output handling from xterm.js.
• Propagate onBell as interface to hook into the bell (make sound output an outer env problem). Here integrators can do whatever they want or suits their purpose.
• Move current direct sound output to a default bell addon, that keeps working in browsers as now, but listens on onBell. If demanded, we could also extend the addon by other bell metaphors, like a visual bell and such.

Issue behind - the current default sound output handling uses an AudioContext internally, which is a rare resource in browser envs (can only be instantiated like 6 times or so). This might lead to weird problems on more complex integrations with multiple terminals. While the SoundService tries to work around that limitation by using a static context instance, it might not work everywhere (e.g. integration already holds all possible instances). The addon separation makes bell handling more flexible, e.g. a complex integration might have its own means to handle onBell, or the addon could be instantiated with an existing audio context instance.

@jerch love it, can you make an issue for that?