Make virtual/computed fields easier to implement

[tyteen4a03]

Currently, implementing virtual fields involves creating two hooks, one for the rendering and one for preventing it from being saved to the database. This isn't very ergonomic for the developer.

There should be a way to declare virtual fields, as well as retain their types (so it should be a property on existing fields, not a brand new field type)

[Gerharddc]

I agree, the "official solution" presented in https://payloadcms.com/posts/blog/learn-how-virtual-fields-can-help-solve-common-cms-challenges which involves using beforeChange and afterRead hooks seems a bit awkward and "hacky" for something that is likely a common use case.

From https://payloadcms.com/docs/fields/relationship#linking-virtual-fields-with-relationships it seems that it is also possible to directly define a field as virtual instead but currently this property only accepts a string. It is not well documented what this string can contain but it seems it can only point to fields from entities referred to in a relationship.

I think it would be great if one could also pass a function to virtual for the more general use-case where a field is computed rather than stored. Supporting this more directly could likely also help solve bugs such as #13089.