Add detailed instructions for making both patch and major/minor release

[cary-ilm]

This documents the way I've been doing it, I'm certainly open to improvements. Certainly a lot of this could conceivably be automated.

The key element for a patch release is the SO version and ABI compatibility, and our SO numbering scheme still needs simplification.

[meshula]

This is thorough and precise, thanks for putting in the effort to write it up! I didn't spot any issues.

[kmilos]

As pointed out elsewhere, it would seem your patch/minor/major update policy w.r.t. SO versioning has, in fact, nothing to do w/ libtool's policy, and is more akin to semantic versioning, no?

In that case, may I suggest eliminating libtool's "current", "revision", and "age" terminology everywhere (and references to libtool) to help avoid potential confusion in the future?

[cary-ilm]

I've updated these instructions based on #1498. which retires any attempt at libtool versioning, and any mention of libtool in the documentation. We now simply append the major.minor.patch semantic release version to the SONAME, so the real file name of the shared library will take the form libOpenEXR.so.31.3.2.0, where 31 is the ABI's SO version, and 3.2.0 is the release version. This has the advantage that no SO versioning info needs to be altered on patch releases.