Before this commit, some aspects of factory flashing (device
enumeration and initial loading of firmware) were handled in
the production flow. However, this interacted poorly with the device
recovery flow, since uploading a production firmware causes
the device to re-enumerate.
* Re-enumeration is not very reliable, especially on Windows. (GlasgowEmbedded#252)
* If more than one device is connected, re-enumeration could cause
  the wrong one to be destructively reflashed, since USB has no
  geographical addressing.
In addition, behavior related to `--force` depended on the device
EEPROM state, which is not appropriate to either factory flashing
or the recovery flows.

This commit solves these issues by separating (and simplifying)
the production and the factory flashing flows.
* The production flow only opens VID_QIHW:PID_GLASGOW devices
  (factory flashed) and loads only the production firmware.
* The factory flashing flow opens VID_CYPRESS:PID_FX2 devices with
  no options, and VID_QIHW:PID_GLASGOW devices with `--reinitialize`.
* The factory flashing flow loads the Cypress bootloader firmware,
  regardless of VID:PID. It ignores the EEPROM contents and flashes
  the configured revision and serial, as well as the built-in
  firmware, and asks the operator to power cycle the device.

The notable differences are:
* The factory flashing flow is incomparably more reliable.
* The factory flashing flow is flashing a firmware in addition to
  the configuration block, halving the amount of programming steps.
* The factory flashing flow no longer attempts to prevent you from
  flashing an already factory flashed device. This might seem bad at
  first glance, but:
  - It was added, IIRC, to handle potential re-enumeration bugs,
    which are no longer present.
  - It actively got in the way most of the time.
  - It's not *that* destructive--you just lose your serial, and
    even that only if you did not have it on a sticker or written
    down somewhere. (If you care about the serial it is probably
    because you have it in a script somewhere, so the problem of
    backing it up solves itself.)

Fixes GlasgowEmbedded#252.

Before this commit, some aspects of factory flashing (device
enumeration and initial loading of firmware) were handled in
the production flow. However, this interacted poorly with the device
recovery flow, since uploading a production firmware causes
the device to re-enumerate.
* Re-enumeration is not very reliable, especially on Windows. (GlasgowEmbedded#252)
* If more than one device is connected, re-enumeration could cause
  the wrong one to be destructively reflashed, since USB has no
  geographical addressing.
In addition, behavior related to `--force` depended on the device
EEPROM state, which is not appropriate to either factory flashing
or the recovery flows.

This commit solves these issues by separating (and simplifying)
the production and the factory flashing flows.
* The production flow only opens VID_QIHW:PID_GLASGOW devices
  (factory flashed) and loads only the production firmware.
* The factory flashing flow opens VID_CYPRESS:PID_FX2 devices with
  no options, and VID_QIHW:PID_GLASGOW devices with `--reinitialize`.
* The factory flashing flow loads the Cypress bootloader firmware,
  regardless of VID:PID. It ignores the EEPROM contents and flashes
  the configured revision and serial, as well as the built-in
  firmware, and asks the operator to power cycle the device.

The notable differences are:
* The factory flashing flow is incomparably more reliable.
* The factory flashing flow is flashing a firmware in addition to
  the configuration block, halving the amount of programming steps.
* The factory flashing flow no longer attempts to prevent you from
  flashing an already factory flashed device. This might seem bad at
  first glance, but:
  - It was added, IIRC, to handle potential re-enumeration bugs,
    which are no longer present.
  - It actively got in the way most of the time.
  - It's not *that* destructive--you just lose your serial, and
    even that only if you did not have it on a sticker or written
    down somewhere. (If you care about the serial it is probably
    because you have it in a script somewhere, so the problem of
    backing it up solves itself.)

Fixes GlasgowEmbedded#252.

Before this commit, some aspects of factory flashing (device
enumeration and initial loading of firmware) were handled in
the production flow. However, this interacted poorly with the device
recovery flow, since uploading a production firmware causes
the device to re-enumerate.
* Re-enumeration is not very reliable, especially on Windows. (#252)
* If more than one device is connected, re-enumeration could cause
  the wrong one to be destructively reflashed, since USB has no
  geographical addressing.
In addition, behavior related to `--force` depended on the device
EEPROM state, which is not appropriate to either factory flashing
or the recovery flows.

This commit solves these issues by separating (and simplifying)
the production and the factory flashing flows.
* The production flow only opens VID_QIHW:PID_GLASGOW devices
  (factory flashed) and loads only the production firmware.
* The factory flashing flow opens VID_CYPRESS:PID_FX2 devices with
  no options, and VID_QIHW:PID_GLASGOW devices with `--reinitialize`.
* The factory flashing flow loads the Cypress bootloader firmware,
  regardless of VID:PID. It ignores the EEPROM contents and flashes
  the configured revision and serial, as well as the built-in
  firmware, and asks the operator to power cycle the device.

The notable differences are:
* The factory flashing flow is incomparably more reliable.
* The factory flashing flow is flashing a firmware in addition to
  the configuration block, halving the amount of programming steps.
* The factory flashing flow no longer attempts to prevent you from
  flashing an already factory flashed device. This might seem bad at
  first glance, but:
  - It was added, IIRC, to handle potential re-enumeration bugs,
    which are no longer present.
  - It actively got in the way most of the time.
  - It's not *that* destructive--you just lose your serial, and
    even that only if you did not have it on a sticker or written
    down somewhere. (If you care about the serial it is probably
    because you have it in a script somewhere, so the problem of
    backing it up solves itself.)

Fixes #252.