Modify Ticket System to Allow for non-breeding tickets.

[A554551N]

As part of the implementation of #96, we need the ability to generate art tickets that don't involve multiple parents but should still render in the getTicket,showTicket, and getDetailedTicket interfaces. This will certainly require substantial modification to the underlying code for ticket tracking?

Suggested Plan

• Add a 'ticket_type' field to DB to distinguish breeding and modification tickets
• Add an 'ticket_item_consumed' field to DB to indicate what item generated the ticket
• add a code switch for getTicket and getDetailedTicket to render different details based on the type of ticket
• Modification tickets will likely only display the create date, requesting user, item consumed, and a ticket comment string that indicates the requested modification (for future-proofing I'll leave open taking it in as an arg)
• Ticket Statuses may have to be updated to reflect changes to the nature of tickets (for example Breeding in Progress becomes Ticket in Progress

[A554551N]

Completed as part of 0.4.0, not yet merged