Support for custom types in properties

One of the problems I've personally run into with the property editor (and object types, by extension) is that the available types for each property (string, int, float, bool, etc) don't always cover all the different types of things I'd like to store into properties. There are plenty of existing issues about adding more types (arrays, object references, etc) but inevitably there will always be one more type to represent in properties (for example: vector or matrix values)

In my projects I tend to have a very generic tiled-to-custom-map-format parser that doesn't know exactly what type each property is supposed to be, so I end up writing a parser for the "string" type that supports putting vectors or other types into string properties (so something like `(0, 1)` would parse out to a vector). The problem with this is that I also have to support normal string properties, so that involves also writing out a way to escape parenthesis (for example) just in case I need to start an actual string with a `(`.

I'm proposing adding support for "custom" types that map to any existing type of property but have a different type name. In my mind this would work by having the `type` attribute on properties be set to the usual string/int/float/etc that Tiled supports and have an additional attribute named `customType` set to whatever the user specified. This would massively simplify writing custom property types without having to wait for their support in Tiled itself.

Here's an example of how that might look in XML:

```xml

```

Tiled would need to support specifying the `customType` value somehow (+ support in the object types editor), but this would allow external parsers to be given a hint as to how to parse properties that don't fit into Tiled's normal types.

Start by reviewing the property editor and object types editor described in the issue, then trace how properties are represented and written to XML. Done means users can specify a customType while retaining an existing property type, and external parsers can see that custom name in the exported representation.

Written by the indexing model from the issue text.