Make subject filters a first class entity

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.

Start by reviewing the SSF specification and the add_subject and remove_subject endpoints, including how Subject and default_subjects are currently used. Define the SubjectFilter model and its wildcard or regex behavior, then update the specification so both endpoints accept it and receivers can match all subjects. Done means the revised semantics are documented consistently without relying on separate default behavior.