Add metrics to be able to identify leaking prebuild

[geropl]

Came up in the context of:

• [prebuild] Not starting workspace once the prebuild is done #8195: prebuilds are stuck in running because of an (suspected) supervisor bug (@AlexTugarev please fill in issue id HERE once created 🙏 )
• Prebuilds are stuck in 'queued' #9395 (comment): prebuilds are stuck in queued for multiple reasons

First idea:

• have counters on "queued" (WorkspaceFactory in server), "running" and end states ("available", "failed", in bridge, while making sure to only capture flanks 👍 )
• subtracting those should give a fairly good trend

[geropl]

Summary of discussion with @laushinka 👍 :

• (init) decision "do we want to run this"?:
  • no: "aborted"
  • yes: "queued"
    • -> "running" -> end state
    • -> end state
    • end state is:
      • system error: "failed" | "timeout"
      • user error: "aborted" (stopped by request) | "available" + error (user tasks failed)
• maybe create an image fo the state machine here?

[geropl]

metrics:

• a) prebuild_state_counter { state }
• b) prebuild_started_counter + prebuild_finished_counter
• c) ...?

[laushinka]

Just noticed that we have prebuild_queue_size metric which is not used anywhere it seems.