Figure out and implement media types

This comment responds to comments #14 to #18 in #2103293: Terminology proposal(s).

"One" should be just a special case of "many". I think that we should design media type vs. media bundle relationship with this in mind. Implementations of Scald and Asset should definitely be taken into consideration, but I think that this are not the only two possible approaches. One interesting and certanly possible approach was proposed in #2099735-29: Create basic entity type definition.

Added comment about types.

I discussed this with @jcisio in NYC but we didn't come to any conclusions. On my flight back home I spent few hour analysing different possible solutions and identifying various aspects of them. This are my results:

1. Field API fields are used to store media resources
- we put standard Field API fields on media entity that are used to connect them with media resources (can be image/file fields for local files, link field for remote files, textarea for embed codes, etc.)
- media plugins that are connected to media bundles know how to provide additional informations about media resource itself (thumbnails, ...)
- (+) upload: via entity browser/creator - entites are created and resources stored into fields in one step
- (+) display in Entity render context: configured via display configuration on media entity
- (o) display in Field formatter context (on parent entity): needs custom entityreference formatters; we could try to implement "inherit formatter", which inherit formatter from media entity
- (+) views: simple to use as we use standard fields
- (+) thumbnail: special view mode or implemenation on media plugin could be used
- (+) allows us to create complex media entities (e.g. YT video (link field) + locally stored and overridable thumbnail (image field))
- (-) more media plugins per media bundle are possible but can result in unused fields (if media plugins use different fields)

(+) 5x; (-) 1x; (o) 1x

2. Properties on media entity itself (Resource ID, plugin id)
- we have two properties on media_entity; resource ID and plugin ID; only plugin will know what resource ID actually means
- (-) can be used to store single values only; we could use fields to store multi-value resources, but this basically ends up being same as option 1
- (+) upload: via entity browser/creator - entites are created and resource stored into property in one step
- (-) display in Entity render context: media plugin is responsible for creating markup representation of media resource
- (-) display in Field formatter context: needs custom entityreference formatters
- (-) views: needs custom views integration; media plugin is responsible
- (-) thumbnail: custom implementation: media plugin is responsible

(+) 1x; (-) 5x; (o) 0x

3. "Media resource" field used on media entity
- we would implement special field type, where each item stores two values (resource ID, plugin ID) - this allows us to store multiple resources provied by different media plugins
- media resource is similar to entityreference, except for the fact that is not limited only to entities
- (o) allows us to create complex media entities (YT + thumb example form opt. 1), but it is hard to determine which plugin (if any) is responsible for data outside of "media resources" field
- we could fix that with two levels of media plugins (single item level and global level), which adds additional complexity
- (+) upload: via entity browser/creator - entites are created and resources stored into "media resources" field in one step
- (-) display in Entity render context: custom formatters and/or media plugins are responsible for markup representation
- (-) display in Field formatter context (on parent entity): we need custom formatters for custom field type
- (-) views: needs custom implementation
- (-) thumbnail: plugin is responsible (custom implementation)

(-) 4x; (-) 1x; (o) 1x

4. Media entity that uses entity reference to bring in media resources
- needs 2 entity types
- adds a lot of complexity
- upload, display, views and thumbnails become much more complicated
- probably the worst solution of all

Legend:
(+) advantage/good
(o) average
(-) disadvantage/bad

Please comment!

Also... while having semantic bundles is great I'm more and more convinced that we should integrate taxonomy out of the box. When thinking about this I realized that I missed good taxonomy integration in all D7 solutions. It is easy to add a field to an entity but this is not enough. Taxonomy should be nicely integrated with media browser, upload/create flow, ...

It is also important to note that taxonomy does not exclude semantic bundles.

Thanks!