Offer two-way conversion of supported BpmnElementTypes to BpmnModelConstants

[RomanJRW]

Is your feature request related to a problem? Please describe.
In Optimize, we import Runtime engine activity instances and store it's type as part of Optimize's activity instance data structure. For example, a start event from the engine will have type startEvent (or any other type from BpmnModelConstants). We use these types for some of our reports and the underlying aggregations. Think of a user task report, this will filter for all activity instances that have type userTask.

Now that we also import Zeebe process instance data, we have the following problem:

• Zeebe process instance records have their own bpmnElementType, which is independent from the runtime engine. When we read a process instance event that has been exported from Zeebe, we extract the type and now see a value like USER_TASK. Before we save that in Optimize, we need to convert it to be userTask to make it work. Currently we have a basic switch statement for this conversion
• If a new BpmnElementType is added to Zeebe (like with SEND_TASK in the most recent release), Optimize doesn't know how to make this conversion to its BpmnModelConstants representation and the import fails for that activity.

Describe the solution you'd like
Rather than Optimize needing to support the same list of supported elements for the reverse conversion, I think it makes sense for Zeebe to allow conversion of each enum field back to its BpmnModelConstants String representation as part of the enum itself.

Describe alternatives you've considered

• Handling this in Optimize would be tolerable, but an unknown change to the enum breaks the import, as described above
• Saving the bpmnElementType string isn't an option we would like to explore, as Optimize is quite tightly built around the existing BpmnModelConstants we get from the runtime engine. If we ever want to support both zeebe and the runtime engine in the same Optimize instance, this would make things awkward

Additional context
This could probably be done at the same time as #7290