(Mostly) Bug Fixes for writing Strings

[joshday]

The main thing here is fixing some string write bugs (places where length should've been ncodeunits).

There's a few other minor things such as:

• Support for writing Char.
• Strings are now padded by '\0' instead of ' '. I think this is the "correct" way but now I can't actually find the resource I used that said this. I'm fine to either keep or drop this change.
• Changed tests to not depend on a.dbf file in the test directory. Instead we write a DataFrame to dbf so that we know right away what the data is supposed to look like.
• DBFTables.write(path::String, table) now returns the path instead of bytes written.

[visr]

Strings are now padded by '\0' instead of ' '. I think this is the "correct" way but now I can't actually find the resource I used that said this.

I checked the references in the README: https://github.com/JuliaData/DBFTables.jl?tab=readme-ov-file#format-description-resources.
In https://www.independent-software.com/dbase-dbf-dbt-file-format.html it mentions that data is padded with spaces, but field names are padded with NULL bytes. So I think the current padding is correct. Did you run into any related issues with this?

I'm in favor of throwing an error instead of warning and truncating strings that are too long, but technically this is a breaking change. If you think it's harmless, we should at least clearly communicate the behavior change in this PR.

Otherwise, this looks good to me, nice fixes and test improvements.

[joshday]

In https://www.independent-software.com/dbase-dbf-dbt-file-format.html it mentions that data is padded with spaces, but field names are padded with NULL bytes. So I think the current padding is correct. Did you run into any related issues with this?

No issues, but I may have been skimming over resources too quickly and confused the field name padding with the string padding. I did run into some data in the wild that was padded with '\0', but that's easy to handle on read. I've reverted this.

I'm in favor of throwing an error instead of warning and truncating strings that are too long, but technically this is a breaking change. If you think it's harmless, we should at least clearly communicate the behavior change in this PR.

I think it's harmless/the most correct thing to do, but I'm going to add a "DBF Quirks" section to the README since this isn't the only weird thing users might want to be aware of.