Change to using version number instead of /etc/version

[Eeems]

As /etc/version has become static in newer versions of the OS, it's no longer useful for determining what OS version the user is on. Instead, /usr/share/remarkable/update.conf can be parsed to determine the version number returned by the line that starts with REMARKABLE_RELEASE_VERSION=.

I've bumped the library version number to 1.0.2 1.1.0 as part of this due to how it completely breaks existing configuration. I avoided a major version bump, as the actual runtime compatibility doesn't change at all.

I've also updated all references to the old 1.0.0 and 1.0.1 numbers to 1.1.0 1.0.2, as well as updated the github action to run the build on pull requests.

[jwoglom]

Just wondering -- as far as I can tell, this PR is one part of unblocking rm2fb from working on newer firmware versions. Is there any explicit list of what additional work is necessary being tracked on GitHub? I'd be interested in helping, but it's not clear to me as an observer how much work is needed and of what shape.

cc @ddvk

[Eeems]

Just wondering -- as far as I can tell, this PR is one part of unblocking rm2fb from working on newer firmware versions. Is there any explicit list of what additional work is necessary being tracked on GitHub? I'd be interested in helping, but it's not clear to me as an observer how much work is needed and of what shape.

This is not to unblock anything, just start the future proofing a known issue we will encounter.

As for what is needed to support a new version:
#18
https://github.com/ddvk/remarkable2-framebuffer/tree/master/tutorial

[Eeems]

Note to self, after discussion with @raisjn, we've decided against incrementing the library ABI version. I'll have to undo that. It may also be worth adding support for the old configuration somehow, either with a version matrix, or by allowing old /etc/version values for OS versions up to 3.3.2.1666, and force version number for anything we support in the future.