Use Semantic Versioning for explicit library integration

[jserv]

Under this scheme Semantic Versioning (SemVer), version numbers and the way they change convey meaning about the underlying code and what has been modified from one version to the next. That is, dcurl using Semantic Versioning MUST declare a public API, and it should treat all of these scenarios in the same way.

Expected output:

1. Label release versioning;
2. Release SemVer-friendly package(s);
3. API documentation specifying SemVer;

[marktwtn]

Current public API would be:

bool dcurl_init():
Resource allocation.

int8_t dcurl_entry(int8_t *trytes, int mwm, int threads)
Assign a hardware platform, do the PoW and get the result.

void dcurl_destroy():
Resource release.

[wusyong]

@marktwtn I think API documentation can simply put in README if thats all. By the way, where will the version number be placed at?

[jserv]

At the moment, we don't have to think of the API compatibility, and some macros in public header would be functional from the perspective of SemVer. That is, something like DCURL_MAJOR and DCURL_MINOR.
Reference: https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html

[marktwtn]

We already have the version 0.1.0 API document in #115,
and have a tag of v0.1.0 on master branch.

After I finish writing the change log of the version 0.1.0 and create the release, the issue can be closed.

[marktwtn]

The version 0.1.0 has been released!
The issue can be closed now.