Conditional Field Formatting

[melton-jason]

Thoughts on Implementation
I would much rather prefer a more general approach to implement #5232. This implementation is definitely hacky: Specify expects there to be a singular formatter for a field.
A lot of the code in this PR is trying to work around that fact, and allow more than one format be valid for a field at a time. Additionally, this implementation inherently couples the formatter with the state of an object (which makes things difficult as the relevant fields of the object are subject to be null value and there can be changes in field values); given the nature of the requirement this may be unavoidable, but we can get around the other difficulty of Specify expecting only a singular format.

A better solution would be to be enable conditional field formatters.

We could follow a similar format to Table Formats. Imagine something like the following:

<format system="false" name="FormatName" class="edu.ku.brc.specify.datamodel.CollectionObject" fieldname="catalogNumber">
	<switch field="collectionObjectType">
		<!-- The 'default' format to use if no other values match-->
                <!-- We can add a default attribute or similar to this element if desired-->
		<fields>
			<field type="numeric" size="9" inc="true"/>
		</fields>
		<fields value="/api/specify/collectionobjecttype/1">
			<field type="constant" size="3" value="MIN"/>
			<field type="separator" size="1" value="-"/>
			<field type="numeric" size="6" inc="true"/>
		</fields>
		<fields value="/api/specify/collectionobjecttype/2">
			<field type="constant" size="4" value="ROCK"/>
			<field type="separator" size="1" value="-"/>
			<field type="numeric" size="6" inc="true"/>
		</fields>
	</switch>
</format>

or even better if we support dot notation!

<format system="false" name="FormatName" class="edu.ku.brc.specify.datamodel.CollectionObject" fieldname="catalogNumber">
	<switch field="collectionObjectType.name">
		<!-- The 'default' format to use if no other values match-->
                 <!-- We can add a default attribute or similar to this element if desired-->
		<fields>
			<field type="numeric" size="9" inc="true"/>
		</fields>
		<fields value="Mineral">
			<field type="constant" size="3" value="MIN"/>
			<field type="separator" size="1" value="-"/>
			<field type="numeric" size="6" inc="true"/>
		</fields>
		<fields value="Rock">
			<field type="constant" size="4" value="ROCK"/>
			<field type="separator" size="1" value="-"/>
			<field type="numeric" size="6" inc="true"/>
		</fields>
	</switch>
</format>

Another solution may be to introduce a format which only acts as a "bridge" between other formats based on field values.
Down to discuss other solutions as well!

Conditional Field Formatting Compared with Current Solution:

• Expands the functionality to other fields in other tables
  • Not everyone uses (just) catalogNumber as an identifier for a specimen record!
• No hyper-specific and/or confusing documentation is required to explain the setup/behavior of why this field differs from all others
  • There doesn't even need to be a catalogNumberFormatName field on CollectionObjectType!
• There are generally more edge-cases to consider: at least one for each different 'type' of field value, required/nullable fields, etc.
  • This would lead to a greater time expenditure in writing automated tests and physically testing the component
• Setup for the user to meet Implement Catalog Numbering Configurations Based on COT #5232 requirements is the same! Without dot notation, only the order in which they define the format and create the COT would change

Initially from #5431

[maxpatiiuk]

Since field formatters can be conditional, and you can include a record formatter inside a field formatter, can that be used to 'workaround' this limitation? (include a conditional field formatter inside a record formatter to achieve a conditional record formatter)