Expose typed options from OptionsService through terminal.options

[silamon]

This PR makes it possible to use typed options in the terminal addons. Much or less the example from one of the related issues.

// before
term.setOption('rendererType', 'dom');

// after
term.options.rendererType = 'dom';

As far as I am aware, this doesn't introduce breaking changes (yet).

There are some following up possibilities:

• Align the ITerminalOptions in typings again with ITerminalOptions in code. That is, remove the undefined ? from the options, and make the constructor take a Partial<ITerminalOptions> instead of ITerminalOptions. We can assure that all options are filled in with their default values if the options are passed through to OptionsService. This would be a breaking change whatsoever, but allows to remove a lot of undefined checks.
• Start replacing getOption and setOption in the codebase to use the getter and setters of ITerminalOptions.
• Consider to deprecate and remove the getOption and setOption methods in favor of getters and setters.

Related: #2522, #3369

[Tyriar]

Added @deprecated to old APIs, labelling with breaking change to remind me to note it in release notes (even though it's not actually breaking).

[Tyriar]

Looks great, thanks I've wanted this for quite a while 🎉

[jerch]

This PR creates a significant perf decrease in common modules, which have to ask option service for options (e.g. Inputhandler.print alone decreases by ~20%).
Reason behind:

xterm.js/src/common/services/OptionsService.ts

Lines 98 to 107 in 0bc02d6

	get: () => {
	if (!(propName in DEFAULT_OPTIONS)) {
	throw new Error(`No option with key "${propName}"`);
	}
	return this._options[propName];
	},
	set: (value: any) => {
	if (!(propName in DEFAULT_OPTIONS)) {
	throw new Error(`No option with key "${propName}"`);
	}

Fix: dont use getter/setter in fast path code.