Consolidate/deprecate update_version.sh scripts and adjust VERSION

[rocodes]

Description

Post monorepo / debianization refactor: The individual components still have update_version.sh, and I wonder if we can DRY that up a little, or deprecate it. Also, I noticed that a component's idea of its version is wrong (the VERSION file is not updated when we build-debs.sh) but maybe this is WIP.

Steps to Reproduce

(first issue) Visual observation of files
(second issue) build-debs.sh and observe 0.9.0 debs being built. then inspect VERSION in a component and notice a different number (eg 0.3.0 for securedrop-export).

Expected Behavior

• Version number is consistent
• update_version.sh only in one place, if we keep it, or removed

Actual Behavior

Please provide screenshots where appropriate.

Comments

Suggestions to fix, any other relevant information.

[legoktm]

The plan is that there is one version going forwards, that applies to all the components. So we don't need individual update scripts anymore, that can be consolidated.

Now, there are a few places where the version is being used in a user facing way:

client/securedrop_client/gui/main.py
30:from securedrop_client import __version__, state
65:        self.setWindowTitle(_("SecureDrop Client {}").format(__version__))

client/securedrop_client/gui/auth/dialog.py
36:from securedrop_client import __version__ as sd_version
130:        application_version = QLabel(_("SecureDrop Client v{}").format(sd_version))

export/securedrop_export/main.py
19:from securedrop_export import __version__
51:        logger.info("Starting SecureDrop Export {}".format(__version__))

Presumably the export case isn't as important and just for internal debugging but I think it should be reasonable to keep. I think there are two ways we can handle this:

1. Have a new update_version.sh script that continues to update __version__ in the components that need it.
2. Have the package build process inject the version at build time, which prevents any wrong versions from coming in.

I think no. 2 is more "pure" as a solution but it's also more magical and it doesn't work properly in dev. No. 1 is also what we've basically done so far so I'm inclined to implement it for now. PR incoming shortly.