Is your feature request related to a problem? Please describe.
This is an issue to flesh out the discussion in #1407. It aims to describe how the discussed solution would be implemented. The goals are:

1. Generalise the use of placeholders so that they can be used in places other than in generating the slug field.
2. Add a uuid placeholder that is replaced by a UUID.
3. Enable the use of placeholders within widgets' default field.

Proposed Solution

1. Extract token replacement / placeholders to separate until that allows a configurable map of tokens to be supplied.

• Extract functionality in slugformatter to a formatter utility to make it generic. Allow a map of tokens => functions to be passed in to customise the behaviour. This way the supported tokens can be varied based on where the formatter is used.
• Configure a formatter to replicate current slug formatter functionality.
  Note: At this point, functionality should be identical to present.

2. Add uuid field to the placeholder tokens supported by the slug formatter.

• Create a function for generating a uuid that wraps [uuid lib]https://www.npmjs.com/package/uuid), using uuidv1().
• This will allow a uuid to be used inside slugs which I think is worthwhile.

3. Add formatting to widget's default value resolution.

• Create a new Formatter for use in processing a widget's default field.
• Currently there is a check for a default value. If a default value exists it should be run through the formatter and the returned value set as the defaultValue.

There are some further questions, but I don't think they necessarily need to be resolved now and could be added later to keep this feature small and focussed:

• Could user-defined placeholder functions be supported?
• Should a UUID field be added by default to all collection items?
• Could this be opt-in and enabled by a setting on the collection?
• Should there be a mechanism to add a UUID to existing collection items if one doesn't exist?
• Should relations default to using a uuid prop as the value for valueField?

Note: I have a little time over the next week and should be able to get this done if the above is acceptable.

Describe alternatives you've considered
There is the alternative described in #1407 which involves creating a widget to dynamically supply a UID. However I think a more low-level solution is preferable. Relations should not be being declared based on properties that can be edited by a user. This solution allows a stable field to be created at creation time and set as a hidden widget to prevent user-editing.