Add constructors, setters, adders & builders

[fengalin]

This MR adds constructors, setters, adders & builders.

Constructors arguments include all non-optionals & non-collections attributes. String arguments use impl ToString.

When only one argument is optional (e.g. Attribute), an additional constructor with_... is implemented, otherwise setters / adders & builders are defined.

Adding an Attribute to a Session or a Media uses direct impl ToString arguments so we can write:

media.add_attribute("attr");
media.add_attribute_with_value("attr", "value");

instead of:

media.add_attribute(Attribute::new("attr"));
media.add_attribute(Attribute::new_with_value("attr"));

Same for other builder-less argument types: Connection, TimeZone & Key.

The second commit adds shortcuts to define the rtpmap attribute.

Example:

sdp_types::Session::builder(
    sdp_types::Origin::new(
        session_id,
        0,
        sdp_types::ADDRTYPE_IP4,
        sender_addr,
    ),
    "rtpbin2-precise-sync-example",
)
.connection(sdp_types::ADDRTYPE_IP4, outbound_addr)
.attribute("sendonly")
.media(
    sdp_types::Media::builder("audio", outbound_port, "RTP/AVP", pt)
        .rtpmap_with_params(pt, encoding_name, AUDIO_RATE, AUDIO_CHANNELS)
        .attribute_with_value("ts-refclk", refclk)
        .attribute_with_value("mediaclk", clksrc)
        .attribute(format!("ssrc:{ssrc} cname:{cname}"))
        .attribute("rtcp-mux")
        .build(),
)
.build()

Fixes #5

[fengalin]

an rtpmap parser might be useful too

[sdroege]

here and elsewhere I'm wondering why the builders don't take e.g. Connection directly here, but instead provide smaller setters

[fengalin]

Ah, I thought about mentioning it in the top comment, but then I forgot...

Connection, Attribute, Key and others have only two construction variants, so I thought it was more convenient and less verbose to include a direct setter in the builder. Ex:

    .connection(sdp_types::ADDRTYPE_IP4, outbound_addr)

instead of:

```rust
    .connection(sdp_types::Connection::new(sdp_types::ADDRTYPE_IP4, outbound_addr))

I could also use this for Origin btw.

[sdroege]

That makes sense but maybe a generic one based on the struct would also make sense (if you want to copy over a Connection from some other session or so)?

[sdroege]

I wonder if this shouldn't be some kind of attribute builder

[fengalin]

As you wish. Related to previous comment.

[sdroege]

I don't mean that this should be removed but should probably be some kind of specific attribute builder instead

[sdroege]

Looks good to me otherwise, thanks!

[fengalin]

What do you think about this?

an rtpmap parser might be useful too

[sdroege]

an rtpmap parser might be useful too

Yes, see also #25

[fengalin]

Maybe we should also add get_attributes_for_ssrc variants that would return the attributes as seen by current source, removing the need for the user to deal with ssrc:<ssrc> <attr> level and returning the most significant one. E.g. for ts-refclk, we want by order or priority, the ssrc-level, the media-level or the session-level attribute.

[fengalin]

Just discussed with Tarun about my comment above. He already implemented the group attribute handling as part of this PR.

In a separate PR, we could define some kind of view / lens mechanism where a user gets a version of the SDP filtered for a specific SSRC.

[sdroege]

Sounds good to me. Let me know (both of you) when you want either/both of the PRs merged. From my point of view this is all ready.