Docs: LintMessage.line and column are possibly undefined

[btmills]

Prerequisites checklist

• I have read the contributing guidelines.

What is the purpose of this pull request? (put an "X" next to an item)

[x] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:

What changes did you make? (Give an overview)

In lib/linter/linter.js, the parse() function's exception handler translates the exception's message to a LintMessage. It also passes through the exception's lineNumber and column, but the exception is not guaranteed to have those properties. In that case, LintMessage.line and column can be undefined.

eslint/lib/linter/linter.js

Lines 693 to 711 in f966fe6

	} catch (ex) {
	// If the message includes a leading line number, strip it:
	const message = `Parsing error: ${ex.message.replace(/^line \d+:/iu, "").trim()}`;
	debug("%s\n%s", message, ex.stack);
	return {
	success: false,
	error: {
	ruleId: null,
	fatal: true,
	severity: 2,
	message,
	line: ex.lineNumber,
	column: ex.column
	}
	};
	}

In eslint/eslint-plugin-markdown#191, the processor would crash when attempting to map messages without a line.

Is there anything you'd like reviewers to focus on?

Normally widening a type like this would be a breaking change, but since this is only updating the docs to reflect reality, I think this can be a semver-patch change.

For the JSDoc type, I used {number|undefined} line instead of {number} [line] because line and column are always present but may have the value undefined.

[nzakas]

LGTM