Resolving merge conflicts from WIringPi/WiringPi:master

https://github.com/WiringPi/WiringPi into WiringPi-master

Updates to gpio help text.

Prep for deb release as 2.70

This is a general tidyup to detach this fork better from Gordon, who was (and perhaps still is) completely inundated with WiringPi-related support questions.

This changeset includes a number of tweaks which should reduce support burden on Gordon. I believe they are essential if we plan to release a new debian package.

They should - hopefully - not reduce or make ambiguous the origins of this code while achieving the above.

* Remove Gordon's email address from all source files to avoid support queries finding their way to him
* Update wiringPi URLs to the GitHub repository to try and keep bugs/issues within the fork
* Bump version to 2.70 ready for a debian package release
* Update debian package maintainer info, add bugs & homepage URLs to this repository

* Changes to support the Zero 2 W (model type 18|0x12)

* Increment version in version.h

* Increment version in debian-template/wiringPi/DEBIAN/control

* Increment version in VERSION as well - I keep missing places where this number is defined

* Increment VERSION_MINOR, missed in previous commits; add missing Pi Z2W model name to piModelNames

Co-authored-by: schwartz <pi@schwartz>
Co-authored-by: PumpkinPi <jack@mirkwood.net>

A recent compiler complains about the sprintf() in authenticate() being able to
write up to 1023 bytes into challenge, which is not possible given that getChallenge()
returns a string 10 bytes smaller than whatever string is in its 1024 byte buffer.
Reducing the size of the buffer in getChallenge() quiets the warning.  It should not
affect anything else, as the challenge string is used as a salt that must be <= 96 bits.

* Updated README.md

This may exist in most cases, but occasionally it does not and it aligns with the way the man page directory is pre-created as well.

Signed-off-by: MichaIng <micha@dietpi.com>

Fixed the Compute Module 4 pin mode setting.

Return error from `softPwmCreate` if `pthread_create` fails

If `pthread_create` fails, `newPin` will never get reset to -1 and process would hang. This change will return from `softPwmCreate` immediately if  `pthread_create` returns a non-zero value and avoid hanging forever.