Message cleanup

[aeons]

This builds on top of #2210, and should not be merged before that.

This PR does the following:

• Remove deprecated Effect{Message,Request,Response}Syntax traits and associated objects
• Remove {Message,Request,Response}Ops and put the removed methods, sans unneeded implicit parameters, directly in the classes
• Deprecate replaceAllHeaders, pointing to withHeaders instead. The other direction of this was done in 0.10, apparently. Currently, all withX methods replace the X. For headers, we have withHeaders that replaces and putHeaders that adds.
• Deprecate withType, which takes a MediaType and just wraps it in a Content-Type
• Deprecate withContentTypeOption, recommending to just do the Option.fold in user code
• Add withoutAttribute and withoutTrailerHeaders to complement the with variants
• Change some defs into lazy vals
• filterHeaders' scaladoc comment said that it would remove all headers that the predicate was true for, while doing the opposite. I have changed the comment to be correct and changed withoutContentType which depended on the behaviour described in the comment.

Many of the methods in the *Ops traits were final. I have kept that where it made sense, but I'm not sure it's needed. Can anyone clarify?

Closes #2224

[aeons]

I'll rebase onto master once #2210 is merged. The diff here will also be quite messy until that happens

[aeons]

I think the appveyor failure is unrelated.

[rossabaker]

This is nice. I mostly question the laziness. Would like to hear from others.

[rossabaker]

Is there a better naming idiom we could adopt here and avoid the overload? I've grown more hostile to those, but don't have a naming suggestion.

[aeons]

I don't have a better idea.

[rossabaker]

I'm skeptical of the value of this and decodeStrict, but more people use them than I realize. I don't know that I want to fight the deprecation battle for something so common, but I dislike having multiple ways to do it.

[aeons]

I would be 👍 on deprecating it. I guess we can look at reports for it for the milestones as a gauge for how much it's used.

[rossabaker]

Deprecation + scalafix is going to be a powerful combination for us for things that can be translated directly. It would be nice if the two start going together once the scalafix lands. I'm comfortable taking this on in a subsequent PR.

[aeons]

Is there a point to having final def vs. def in a subclass of a sealed trait. Does it hint anything to the compiler about inlining?

[rossabaker]

It can theoretically help with static optimizations, but the JVM is pretty smart about what's actually overridden. I would expect it to not make a practical difference at runtime, and it's a question of signaling intent. Here, I don't think it's a huge deal either way.

[rossabaker]

👍

[aeons]

Alright. To be consistent I've made all of them non-final. :)

[ChristopherDavenport]

👍 after resolved