Improve `CompositeKind` handling

[BambOoxX]

The current behavior for CompositeKind data is

MAT.jl/src/MAT_HDF5.jl

Lines 529 to 536 in 355bd1a

	# Write generic CompositeKind as a struct
	function m_write(mfile::MatlabHDF5File, parent::HDF5Parent, name::String, s)
	if isbits(s)
	error("This is the write function for CompositeKind, but the input doesn't fit")
	end
	T = typeof(s)
	m_write(mfile, parent, name, check_struct_keys([string(x) for x in fieldnames(T)]), [getfield(s, x) for x in fieldnames(T)])
	end

however, there are issues with the isbits(s) test, reported in #162,#143 or with simple user types such as

struct MyType
    field1::Int64
    field2::Int64
end

While these types are clearly isbitstypes, I do not see a reason to not allow their conversion the equivalent matlab struct.
Given

MAT.jl/src/MAT_HDF5.jl

Line 535 in 355bd1a

m_write(mfile, parent, name, check_struct_keys([string(x) for x in fieldnames(T)]), [getfield(s, x) for x in fieldnames(T)])

The requirement seems more to be that fieldcount(T) > 0, regardless of the actual bits type.

Can someone confirm this ?

[BambOoxX]

Bump ?

[matthijscox]

I'd like brainstorm about custom type writing. While it's a fun feature to just write types as structs it's causing lots of unexpected behavior, for example when people write tuples or whatever and expect vectors to be written (see #199 ), but we forgot to add explicit tuple writing. Who knows what other types people will try to write.

For custom struct writing we could first enforce people to register their type, either via StructTypes.jl (used by JSON3.jl) or maybe the new StructUtils.jl (used by JSON.jl now, and I see JSON3 is deprecated). People can then also define their own mapping from fields to dict keys (if they want).

Using StructTypes.jl they would have to declare:

StructTypes.StructType(::Type{T}) = StructTypes.DictType()

Using StructUtils.jl, they would have to declare:

StructUtils.dictlike(::Type{MyDict}) = true

And then we only write custom types as structs if they have declared themselves as dicttype (or arrays if declared as arraylike), otherwise we throw an error.

[BambOoxX]

Frankly, that would be very fine for me. It makes things very obvious, and opt-in for people interested in this behavior.