Rework data propagation mechanisms

The previous code was a proof of concept and therefore had a couple of design
issues. Changes to it include:

- More abstraction layers for better type-safety and modularity; The whole API
  now strictly distinguishes between ReadChannels and WriteChannels. By looking
  at the types of a function, it can be easily predicted what the passed channel
  is being used for.
- Due to the new design, data structures can be built on top of channels and
  aggregates. Rose trees and maps were added as examples.
- Improve naming; Var, VarBuf as opposed to CachedChannel or CachedAggregate
- Created unified traits for reactive combinators; as more data structures will
  be added in the future, this ensures consistency amongst them.
- The former aggregates are now Var[T] buffers (rather than Channel[T]); for
  most lists the values would need to be cached anyway, therefore this is now
  the default behaviour. However, it is still possible to create a reactive
  buffer for a Channel[T], or for any other type.
- Back propagation for aggregates was removed completely; for sequences it
  offers very little benefit. Previously, this was only used to back-propagate
  deletions. Removing this feature makes it easier to implement new
  combinators. Similarly, filter() became significantly shorter and better to
  comprehend.
- An aggregate now publishes its changes as a channel (previously a trait
  needed to be implemented); this allows to use any of the combinators defined on
  channels. For example, a change transformer could be written that cancels out
  sequences like:

     Change.Insert(Position.Last, var)
     Change.Remove(Position.Last, var)

- Work on resource management was started, but not entirely finished. We need
  to ensure that callbacks get unregistered correctly, notably when chaining
  combinators.

The refactoring is not complete, though. Many combinators are still missing.
Most importantly, the aggregate test cases are incompatible due to the changes
in the API and semantics. In the past chaining of combinators pointed to many
bugs. Therefore, writing generator-based unit tests would make sense to ensure
proper functioning.

Thanks to @martinring for providing some valuable input.
Buffer: Move toVarMap()
Combinators: Fix signature of partialMap()
VarBuf: Implement trait MapFunctions
OptVar: Should be a channel of Option[Var[T]]
Combinators: Split FilterFunctions

FilterFunctions should only contain combinators operating on values.
ReadVarBuf: Add toVarBuf()
Combinators: Fix signature of flatMap()
Combinators: Add splitAt()
ReadChannel: Add flatMapCh()
VarBuf: Rename unit() and overload initialiser

It can be used for ReadBuffer[Var[T]] as well.
OptVar: Change semantics for better usability
Combinators: Add equal() and clarify contains()
Combinators: Clarify head() and derivatives
Combinators: Add unequal()
VarOpt: get() should dereference the value
OptVar: Rename to Opt
Migrate test cases to otest

otest is a test suite written in Scala. If parts of Widok were reused in JVM
projects, the test cases would be compatible as well.
Channel: Change semantics of dispose() and expose the attached state

Children are now stored in a queue for better performance. Deleting is
O(n) for ArrayBuffers while it can be performed in constant time for
queues.
Property-based testing for channels