Improve naming and documentation around attribute data

[Tyriar]

Current state:

xterm.js/src/common/Types.d.ts

Lines 71 to 100 in 17cb610

	/** Attribute data */
	export interface IAttributeData {
	fg: number;
	bg: number;
	clone(): IAttributeData;
	// flags
	isInverse(): number;
	isBold(): number;
	isUnderline(): number;
	isBlink(): number;
	isInvisible(): number;
	isItalic(): number;
	isDim(): number;
	// color modes
	getFgColorMode(): number;
	getBgColorMode(): number;
	isFgRGB(): boolean;
	isBgRGB(): boolean;
	isFgPalette(): boolean;
	isBgPalette(): boolean;
	isFgDefault(): boolean;
	isBgDefault(): boolean;
	// colors
	getFgColor(): number;
	getBgColor(): number;
	}

Problems:

• fg and bg are very ambiguous
• getFgColor and getBgColor return a number, not an IColor
• Can we improve getFgColorMode and getBgColorMode to return a type ColorMode = CM_DEFAULT | CM_P16 | CM_P256 | CM_RGB instead of number?
• This whole interface could do with some detailed docs, especially since it's probably going to get exposed in xterm.d.ts in Add foreground/background color support for SerializeAddon #2369

[JavaCS3]

If getFgColor, getBgColor returns an Object, it will decrease performance a little bit.

[Tyriar]

@JavaCS3 it would still be a number, just a more precise one:

type ColorMode = CM_DEFAULT | CM_P16 | CM_P256 | CM_RGB
// equivalent to this but with names:
type ColorMode = 0 | 0x1000000 | 0x2000000 | 0x3000000

[JavaCS3]

@JavaCS3 it would still be a number, just a more precise one:

type ColorMode = CM_DEFAULT | CM_P16 | CM_P256 | CM_RGB
// equivalent to this but with names:
type ColorMode = 0 | 0x1000000 | 0x2000000 | 0x3000000

Great

[jerch]

@JavaCS3 Just drop me a note if you have issue to restyle it (since I have created that convoluted mess).

[Tyriar]

@jerch I'm planning on doing this one, but we can carry the changes over to #2369 after

[jerch]

@Tyriar Ah ok, either way would work (and does not bloat #2369 with too much offtopic stuff).