Ideas what could be done in membrane_core v2.0

[FelonEkonom]

v2.0 could bring some API breaking changes, so there is no need to keep the backwards compability

[FelonEkonom]

1. Merge different types of elements into one use Membrane.Element
   Pros: Lower entry threshold.
   Cons: What with auto flow control in Endpoint vs Filter?

[FelonEkonom]

2. Unify API of options of manual and auto pads, e.g. merge auto_demand_size with queue_target_size.
   Note: could be partially done before v2.0.

[FelonEkonom]

3. Pad availability: :optional - as well, could be done before v2.0.

[FelonEkonom]

4. Instead of writing child(:name, ChildModule) or child(:name, %ChildModule{fileds...}), the API could look like ChildModule.child(:name) or ChildModule.child(:name, options).

Pros: Currently spec field in def_options is used only to generate documentation and isn't used neither invalidating a children spec nor in type specification for handle_init/2. This change would allow us to have a type specs for dialyzer in these two places.

Note: options in the proposed solution could be a keyword list or a map. The advantage of using a keyword list is that is would look better, on the other hand using a map provides better typespecs.

[FelonEkonom]

5. Rename :spec action to something different - now, when you talk about "spec", it is ambiguous if you think about :spec action or about a function type specification.
   Maybe :children?