GUACAMOLE-2139: Bump version numbers to 1.6.1.

[mike-jumper]

This change bumps the version numbers of all guacamole-client projects to 1.6.1. In an attempt to reduce maintenance burden, this change also:

• Migrates away from manually listing all compatible versions, instead determining compatibility by comparing major, minor, patch, and suffix.
• Switches all otherwise hard-coded instances of the guacamole-client version to substitutions of ${project.version}, including the various guac-manifest.json files.

Going forward, this will allow us to just update the guacamole-client version with a single command like:

mvn versions:set -DnewVersion="1.6.1" -DprocessAllModules=true -DgenerateBackupPoms=false

[mike-jumper]

I've modified things a bit further to remove all the repeated references to the parent POM version, as Maven supports using a ${revision} property for this since 3.5.0.

The continued references to the guacamole-client version are now strictly in the main parent pom.xml and in the examples beneath doc/ (where the version should remain present for reference).

[necouchman]

Overall I'm good with the changes - the only thing that I wonder if it would be somehow possible to do is something to distinguish between when this new GuacamoleVersion class actually provides a version (the overall Guacamole Client instance) and when the class requires or implements a version (extensions). I'm thinking that there could be situations for folks writing extensions to accidentally reverse the logic in checking the provided vs. required version, and get unexpected results.

I'm not sure it's worth holding up these changes to do that - just a suggestion for something in the future - maybe make GuacamoleVersion into an abstract class and then have a couple of different implementations - RunningGuacamoleVersion and ImplementedGuacamoleVersion or something like that?

Let me know what you think - if you want to go ahead and merge these changes as-is, I'm good with that.

[mike-jumper]

I think I prefer things as they are, mainly because I like conceptualizing the extension versioning as a set of requirements that the running Guacamole version must satisfy ("I need at least version X to be usable"), in which case the idea behind the GuacamoleVersion abstraction is the same regardless of where it's used. Both "implemented" and "running" cases represent a particular Guacamole release and the expected compatibility of that release.