Add user-readable Ticket ID field

[amirozer]

The Need

1. Humans need an easy to read ticket ID/number to reference requests (for example, when calling the hotline to ask for the status of ticket)
2. Ticket IDs can be added to Email subject lines to group communication around a specific request together (both for residents and for staff members)
3. We will want to allow importing tickets from external systems, and will need to store their ticket ID, so we can update an existing ticket in following imports. Unlike our IDs, these IDs are unique to a jurisdiction but not to an instance (the same ID can appear in multiple jurisdictions)

The Solution

1. Add a new field for Ticket Id
2. By default, it will be an auto-increasing number with a year and month prefix. Each month we start counting from 1. For example, the 271st ticket in June 2022 will have the ID "2206271"

[pwalsh]

@amirozer sounds good.

1. We can also create a data migration that backfills these IDs for existing requests.
2. I like the format for the default ID based on date and increment
3. Regarding your point 3, I'm less sure about the use case for allowing an external system to set these IDs in order to continue updating a ticket based on an existing ID from another system. We can't guarantee that these external systems issue IDs that are unique per jurisdiction - eg they may be unique per department for all we know. I'm just not sure it is not better to always issue our own ticket ID based on the format you suggest, which we can guarantee is unique in a given jurisdiction context, and then, if we have a real use case, add a field for external identifier(s).

[amirozer]

@pwalsh re: 3, I've based this requirement on the fact that we have an immediate need to import external systems' data into the platform. We already do this today with dozens of clients, and we already today import the same tickets multiple times, updating existing tickets, so we do need an external reference ID. I'll check if we have any client that has multiple hotlines integrated. If we do, I suggest the import mechanism will optionally add a prefix to ticket numbers, by import source.

[pwalsh]

Shipped in #53