Deprecate get_variant_default

[nealrichardson]

Apparently I forgot to push this to my last PR. Related to #283

[toph-allen]

tl;dr I think this implementation is fine; I don't think we should deprecate get_variant_default() yet. Having a function named get_variant_default() is a lot more obvious to users than passing a special value to get_variant() (because it pops up in autocomplete when you type get_variant vs. requiring that users read the documentation to figure it out).

One option would be to have get_variant(content) return the default variant as its default behavior when no value is passed to key (whether by having "default" be the default argument to key, or having NULL as the default key and returning the default variant when is.null(key)).

Ultimately, though, I think it's a moot point: In a user's mental model, all the actions they might want to take on the default variant of a non-parameterized content item are actions that should involve the content item itself. In that case, those actions should just work with the Content class, getting the default variant behind the scenes (like the approach in #283).

So it probably makes sense to think of get_variant_default(content) as an implementation detail for content-related actions that just happen to live on the default variant, and get_variant as a function users use for workflows with parameterized content. Maybe makes sense to have a content$default_variant() method, but I don't have a clear vision for what direction I think we should take the package's syntactical conventions yet.

Let's start using the lifecycle package to mark deprecations going forwards: https://lifecycle.r-lib.org/articles/manage.html.

[toph-allen]

@nealrichardson I'm gonna go ahead and merge this so that I can integrate it into my branch.