Support for asynchronous tileset sources (and targets)

[javagl]

The tools can currently process tilesets in different representations. The most common one is that of a tileset being stored in the file system, with some tileset.json that essentially points to the content files using relative paths in the content.uri. But they also support tilesets that are stored in 3DTILES files (an SQLite-based database file) or in 3TZ (a ZIP-based storage format).

For the internal processing of the tileset data, these different representations are completely abstracted away: All the operations take place on a TilesetSource and a TilesetTarget. These are interfaces that offer the basic operations that are required for implementing the tools functionality.

Right now, nearly all methods in these interfaces are synchronous. This makes sense for the existing implementations. But it limits the extensibility: If there ever should be a representation of a tileset where any aspect is asynchronous, then this cannot be accomplished with these interfaces.

It could therefore make sense to change this, and to declare all functions of the TilesetSource and TilesetTarget as async. The changes on the usage side should be minor, insofar that it can be handled by just slamming an await before each call.

---

A rant:

I personally don't like that 'async' is viral. When there is a call chain like

function getA() {  return computeA(getB()); }
function getB() {  return computeB(getC()); }
...
function getZ() {  return someLibrary.getZ(); }

and that someLibrary is later swiched to a library that only offers getZ as an async function, then the whole thing breaks down, and one has to pass that async/await though the whole call chain, in a completely breaking change.

This makes so little sense that I thought that there should be a programming language that could just be called 'AsyncScript`, where each and every function call like

function example() {...}
const result = example();

is implicitly and automatically translated into the JavaScript code

async function example() {...}
const result = await example();

(And making this translation 'smart and efficient(!)' should be the job of the compiler)

But given the absence of such a language, my stance is: Functions in basic interfaces should be declared as async by default, because that is literally the only way to be on the safe side and avoid breaking changes with future implementations.

[javagl]

In this context: We should consider adding
"plugin:@typescript-eslint/recommended-requiring-type-checking",
to our linting configuration. Right now, this causes many errors, but these should be reviewed thoroughly. The most important one in the context of the change that was suggested here is the rule
"@typescript-eslint/no-floating-promises": "error"

This makes sure that every async function that is called is actually awaited (or the promise is handled dedicatedly).