Eliminate subtyping around type signal

[aantron]

Several functions in Markup.ml accept narrower types than signal. For example,

markup.ml/src/markup.mli

Line 710 in b4b59ae

val pretty_print : ([> content_signal ] as 'a, 's) stream -> ('a, 's) stream

These functions are difficult to modify freely, for example as in #58.

The only function in Markup.ml that produces a stream with a narrower type than signal is content:

markup.ml/src/markup.mli

Lines 548 to 550 in b4b59ae

	val content : ([< signal ], 's) stream -> (content_signal, 's) stream
	(** Converts a {!signal} stream into a {!content_signal} stream by filtering out
	all signals besides [`Start_element], [`End_element], and [`Text]. *)

If this were just (signal, 's) stream -> (signal, 's) stream, it would force users only to add a wildcard case to any pattern matching they do on the signals. Conversely, the benefit would be a library interface that is shorter, easier to understand, and an implementation that is much easier to edit.

[aantron]

plist-xml is the only publicly-visible project I was able to find that would be affected by this. @alan-j-hu, what do you think about replacing content_signal and most row types in Markup.ml with just signal?

I am considering doing this and re-releasing it as part of a retagged 1.0.0.

Sorry about the churn. I realize you just updated your deps to allow Markup 1.0.0, and now this comes up :P

See #58 (comment) for the current motivation behind doing this. I also had similar issues during the original development of Markup, but I managed to massage all the types in the original release to fit.

[alan-j-hu]

Okay, I just opened a PR on ocaml/opam-repository to downgrade markup back to below 1.0.0.