refactor: reduce dependency on the Client class

[TTtie]

This PR introduces changes that aim to reduce the dependency of data structures on the Client class (and internal cached state in general) in order to prepare for the REST and WS parts of the client being split in #52.

[lnpotter]

Does this mean that you intend to deflate the Client structure by moving some methods and functions?

[TTtie]

Not really. The intended end goal for this PR is to make the data structures account for a possibility of not having internal state given to them and act appropriately if it isn't.

In an ideal case, this should just work (T being an appropriate data structure):

import { T } from "@projectdysnomia/dysnomia";

const rawStruct: RawAPIData<T> = { /* ... */ };

// apiObject is now a fancy wrapper around rawStruct
// It must not error if a Client isn't passed as a second parameter
const apiObject = new T(rawStruct);

// Properties should just work, as they are stored directly on the API object
console.log(apiObject.id);
console.log(apiObject.aThing);

// Calling methods on such an object, however, can end up 
// in an error if a Client is needed to do the operation.
// An error like this will be thrown synchronously in most cases.
// (might possibly be subject to change)
try {
    await apiObject.doSomething();
} catch (err: unknown) {
    if (err instanceof TypeError) {
        console.error("A Client was not available on this apiObject");
    } else {
        console.error("A regular error occurred");
    }
    console.error(err);
}

[TTtie]

this is definitely still on the table, but fwiw, this might be better to do as multiple separate PRs for each thing and probably with slightly better research on this.