Fixed / improved file support (ie. writing), other changes (new tests, cmd-line utilities, more strict interfaces, ...)

[t-w]

There is plenty of changes in this PR. The main points are:

• fixed file write support (#30)
  • works also doing seeks and writes, ie. overwriting the data
  • more tests
• more strict interfaces
  • for better security/readability, everything that should/can be const is set const
• some changes done in function naming (ie. in adf_file)
  • this is a proposition of making the naming more clear in the following way:
  • adf + subsystem (eg. File) + operation (eg. Write)
  • other modules could (eventually) be changed in a similar way
• declarations of some data structures moved to relevant modules (eg. File to adf_file)
• some data structures renamed (indicating adflib's namespace, eg. struct File -> struct AdfFile)
• new command-line utilities (in examples/)
• some simple CI config. ("Actions") is added
  • it executes several types of builds on the 3 platforms available in GH
  • runs only for citest branch (so that it is not overused with every push/merge - some tests are a bit I/O-expensive)
• plenty of misc. small fixes
  • got rid of majority of warnings (ie. int types)
  • fixes in build configs.
  • etc.

Please have a look and let know what you think.

There is still a lot of things to check/improve, eg:

• regarding security (see eg. this comment)
• file write support
  • add truncate

but possibly it could be tagged as 0.8.0 (as 'reasonably working').

[lclevy]

Ok for me for this PR and 0.8.0

[lclevy]

I have no time to follow all proposed changes, sorry. I let @t-w decide when and what to merge

[lclevy]

👍

[t-w]

Thanks for all the checks and insights.

I am aware this is a big PR (bigger that it should be...), but doing this another way would require a year to do things in small chunks discussing every small change... Once the main things will be more-less established (eg. build system configs), it will be more feasible to work in smaller bunches, solving one problem at a time.

So, to conclude, let know if it is OK to merge it (or eg. if you prefer to check something more).

[lclevy]

Ok for merging. And for smaller commits next time 😉