model: Sensor hardware properties

The `Sensor` data type, currently `SensorV2`, defines how to take raw measured values from a particular pin of an embedded microcontroller device (e.g., ESP8266 or ESP32) and transform them into useful data. Pins may be further classified as _real_ or _virtual_. Real pins, such as analog (A) or digital (D) pins, are attached to a physical device. For example, A4 on the ESP32, which is attached to a voltage divider, is "real". Virtual pins, on the other hand, provide an additional layer of abstraction. For example, while a DHT22 combined temperature/humidity sensor is physically connected to a single GPIO (i.e., pin 14 on the ESP32), extracting useful data requires additional computation. In this case, two virtual "X" pins, X50 and X51 respectively, convey computed temperature and humidity values respectively.

Unfortunately, the present schema design does not capture any information about the underlying sensor hardware.

It would be useful to capture properties of the sensor _hardware_, in particular, calibration data that may vary from sensor. For example, in future, DS18B20 temperature sensors will need to be accurately calibrated prior to development and our software will require programmatic access to this data.

It is therefore proposed to add a `Properties` field to the Sensor data type., which would be a `map[string]interface{}` stored as JSON.

_Note: Directly storing a Go map[string]interface{} as a single property isn't natively supported as a distinct, queryable type, hence the need for the JSON represention._

```
type Sensor struct {
// Other Sensor fields...
Properties string `datastore:"metadata,noindex"`
}
```

Properties would include:

- Hardware (e.g., "DS18B20")
- DeploymentDate
- RetirementDate
- Supplier (e.g., "DigiKey")
- CalibrationData

Note that `DeploymentDate` and `RetirementDate` could arguably be promoted to the `Device` entity, since devices tend to get deployed and retired, not just individual sensors.