Make subject filters a first class entity

[FragLegs]

The SSF spec made a good choice relying on the Subject Identifiers specification to identify the subjects being referred to in the events flowing over the stream. However, that same specification is not a good choice as a way for the Receiver to tell the Transmitter what subjects it is interested in. Instead, the add_subject endpoint should take some kind of "subject filter" that allows the Receiver to say, "I want events pertaining to subjects that look like this."

Some evidence for this claim:

• We have seen a lot of requests to be able to say "Give me all subjects whose emails match *@company.com".
• The logic around what it means to add and remove an Alias or Complex subject format via the add_subject and remove_subject endpoints is very confusing.
• We had to implement a fairly confusing "default_subjects" method so that some streams can send all subjects. In fact, many implementations completely skip the add_subject endpoint because it doesn't work as smoothly as it should. Ideally, the Receiver should be able to add a subject filter that matches all subjects instead of having different default behaviors.

To address this problem, we should change the spec so that add_subject and remove_subject take a SubjectFilter instead of Subject as an argument. The SubjectFilter language should be flexible enough to allow for wildcard matching, perhaps even regex matching.