Rewrite type declarations

[JELoohuis]

The data types did not yet reflect the actual type of data they contained, so I made the class definition generic and added a new DataTypes definition using it.

I also took the liberty to rewrite the other definitions based on the types we have built at @athombv/drenso, based on the JS source and runtime introspection.

[RobinBol]

1. data40/48/56 typed incorrectly as DataType<number> - should be DataType<Buffer>
2. data64 missing from type declarations

[RobinBol]

octstr typed as DataType<string> - should be DataType<Buffer>

[RobinBol]

If you call DataTypes.Array8(DataTypes.uint8), Type infers as DataType<number>, producing DataType<Array<DataType<number>>>. The actual runtime value is number[]. Should be:

Array0: <T>(type: DataType<T>) => DataType<Array<T>>

[RobinBol]

Suggested change

	bool: DataType<boolean>,
	bool: DataType<boolean | null>,

[RobinBol]

Suggested change

	class BitMap<Flags extends string | null> {
	class Bitmap<Flags extends string | null> {

[RobinBol]

The PR types map8 as (flags: Array) - a single array argument. But node-zigbee calls it with spread args:

DataTypes.map8('flag1', 'flag2', 'flag3')  // actual usage
DataTypes.map8(['flag1', 'flag2', 'flag3'])  // what PR expects
Runtime accepts (...arg) so spread args is correct. The type should be:

map8: <Flags extends string | null>(...flags: Array<Flags>) => DataType<BitMap<Flags>>

[RobinBol]

The new generic parameter Defs extends Record<string, DataType<any>> is a breaking change for existing consumers. In node-zigbee, all Structs use the old pattern:

Struct<ZdoActiveEndpointsResponse>('name', { status: ZdoStatusCodesDataType, ... })

This passes the output type as the generic, not the defs record. With this change, TS errors on every single Struct call (17+ errors across zigbee and zstack packages).

[RobinBol]

The DataType constructor is not exposed in the type declarations, but consumers create custom DataType instances directly. For example in node-zigbee's zdoStructs.mts:

new DataType(NaN, 'ZdoComplexDescriptor', 0, toBufFn, fromBufFn)

This currently errors with Expected 0 arguments, but got 5. The constructor needs to be declared:

constructor(id: number, shortName: string, length: number, toBuf: (...) => number, fromBuf: (...) => Value, ...args: unknown[]);

[RobinBol]

buffer should be optional here. The runtime allocates a buffer internally when called without arguments (toBuffer() with no args), and existing consumers rely on this:

const buf = instance.toBuffer(); // valid at runtime, errors with these types

Should be:

toBuffer: (buffer?: Buffer, index?: number) => Buffer;

[RobinBol]

Same issue as the map types - the runtime uses (...arg) rest params, and some consumers spread additional args. In node-zigbee/zstack this causes TS2556: A spread argument must either have a tuple type or be passed to a rest parameter and TS2554: Expected 1 arguments, but got N errors.