feat: Detect inline XML fragments & views (reuse TS program)

[d3xter666]

JIRA: CPOUI5FOUNDATION-986

This is alternative implementation of #517 by reusing program instead of TS transpiling file by file.

Note: This change's base is currently #518 as it paves the ground for dynamic addition of resources to the TS program

[d3xter666]

Note: This change sorts messages in the tests, so that many unrelated test snapshots are also included in here.
The reasoning is that XML extraction is not stable, so the order of the messages in different runs/OS might be shuffled.

[matz3]

Note: This change sorts messages in the tests, so that many unrelated test snapshots are also included in here. The reasoning is that XML extraction is not stable, so the order of the messages in different runs/OS might be shuffled.

Currently, the linting results are deterministic and we should stick with that. Only sorting the results when comparing within unit tests will not lead to deterministic results for public consumers.

I suspect that this is caused by a missing sorting of the newly created files. For the initial files, this is done via:

ui5-linter/src/linter/ui5Types/TypeLinter.ts

Lines 87 to 88 in 70ad529

	// Sort paths to ensure consistent order (helps with debugging and comparing verbose/silly logs)
	pathsToLint.sort((a, b) => a.localeCompare(b));

[matz3]

The same check is done again below in isXmlInJsCreationCall isn't it?
I wonder whether it would be easier to combine isXmlInJsCreationCall and getViewTypeFromXMLInJsCreationCall as they are very similar. Also, as a CallExpression is required, wouldn't it be better to use the CallExpression as indication node to start the checking instead of the isObjectLiteralExpression inside?

[matz3]

I would expect that this fits into the same category as the partial deprecations, where we perform checks for a specific function call of a module / class.

[matz3]

I'm not sure whether this is the best way to only lint the new files. It currently causes files that have parsing errors like "Unexpected aggregation within an aggregation" to be linted twice. Ideally, we only pass the list of resources that should be linted from outside.

[matz3]

I would expect that this fits into the same category as the partial deprecations, where we perform checks for a specific function call of a module / class.