Add protection against loosing usage data when Spoolman is unavailable when committing usage

[mdziekon]

Description

Since Spoolman is an external entity, there's an edge case, where an unavailable instance of Spoolman could cause loosing usage data. There are multiple ways to "fix" this:

• Introduce retries on usage comitting
  • This fixes cases where Spoolman's instance is only temporarily unavailable (eg. short connectivity issue)
  • Should be easy to introduce
• Store uncommited data in memory
  • This fixes cases where Spoolman's instance is unavailable for longer period of time
  • Requires retry triggering mechanism
    • Either autonomic timer
    • Or manual trigger button in the UI
  • UI should inform about uncommited data and take that into account when calculating "remaining weight"
  • UI not that easy to populate, required API call to retrieve memory data
  • Shutdown of Octoprint will cause loss of data, so not ideally fault tolerant
• Store uncommited data in plugin's settings
  • Fixes the same case as solution above
  • Octoprint-issues tolerant (data persisted across Octoprint runs)
  • Requires retry triggering mechanism
    • Same as above
  • UI should inform about uncommited data and take that into account when calculating "remaining weight"
  • UI easier to populate, as Knockout's observers can be used in JS
  • Potential "settings have changed, restart Octoprint" modals

[mdziekon]

Introduce retries on usage comitting

This basic mechanism has been implemented in #23

[mdziekon]

Related PR: #59