Remove distinction between offer/answer constraints in constructor

[feross]

This issue was raised in a comment by @nazar-pc and didn't want it to get lost:

I have a generic concern about constraints separation. Second argument constraints in RTCPeerConnection was removed from the spec a long time ago. At the same time answer/offer constraints are obvious from the context.

I'd like to see a single peer.setConstraints() method that under the hood resolves to either offerConstraints or answerConstraints and do not even expose this separation for the user. In future major version I'd remove this separation entirely in constructor options too.

Originally posted by @nazar-pc in #324 (comment)

[nazar-pc]

It was actually implemented in mentioned PR with a subsequent commit: 692d18e
Also constraints were replaced with options in #440 and peer.setConstraints() is gone.

So it seems there is nothing left to do here.

[feross]

Thanks for the response @nazar-pc. I actually opened this issue because I was wondering if it's possible to eliminate the distinction between offerOptions and answerOptions. It seems that that can be determined purely based on the value of the initiator option.

In fact, setting { initiator: true, answerOptions: { ... } will cause answerOptions to be ignored. It's a minor API detail, but wondering if we can't make this cleaner?

[t-mullen]

Yes, the options objects should be merged into one.

The fact there is two objects is a leftover from when I planned to have non-initiators also send offers during renegotiation.

It's unfortunate to kick off a major version for something so trivial though.

[nazar-pc]

#530 is not released yet, so it can be released together