Update plugin

Pull in git updates for plugin {RepoName}: the checked-out branch's tip, or, when the versions[] entry for this FPP pins a sha the clone has not passed, that sha and no further. Before the plugin's own fpp_upgrade.sh (or fpp_install.sh) runs, its declared dependencies are reconciled against the new version: newly declared apt, Python and script dependencies are installed, and package claims the new version no longer declares are released (apt-removed once nothing else needs them). A newly declared dependency plugin is reported, not installed -- the operator has to see its privacy disclosure on the Plugins page. Supports ?stream=true. When the privacy block the update would land differs materially from the one accepted for this plugin, the update is refused unless the POST body is {"privacyAccepted": <block>} with that block. Only the FPP Plugins page may send privacyAccepted, and only with a block it actually showed the operator (GET /plugin/{RepoName}/privacy; its Update and Update All both do). Scripts and other API clients POST no body -- not even by echoing pending back from a refusal: on Code: "PrivacyMismatch" they stop and send the operator to the Plugins page. The server cannot tell callers apart, so this is a rule for clients, not something it enforces. Refused on privacy grounds (the same shape as POST /api/plugin): {"Status": "Error", "Code": "PrivacyMismatch", "reason": "mismatch", "Message": "…", "privacyChanged": true, "plugin": "fpp-matrixtools", "pending": {"sends": [], "remoteAccess": "none"}}.