generalize lift() and @lift()

[aplavin]

@lift: allow single observable, or no observables at all
lift: allow operating on non-observables

Motivation:
this enables preparing plotting arguments without manually handling observable and non-observable cases, like

# works no matter if x is a regular value or observable
y = lift(myfunc, x)
# or
y = @lift myfunc($x)

plot(y)

Fixes #3801.

[asinghvi17]

If we're doing this, then lift should always return an Observable, no? This way there's a guarantee of what is happening (and lift becomes somewhat type stable)

[aplavin]

If we're doing this, then lift should always return an Observable

Why?
It seems natural to return an observable whenever needed – so, whenever there is at least one observable in the arguments.

This nicely fits the conceptual meaning of "lift the passed function to the domain of observables" – surely should be a no-op if no observables are actually passed, right?

[aplavin]

bump :)

[aplavin]

bump...

[aplavin]

bump...

[jkrumbiegel]

Not sure if I like enabling non-observable arguments. In what use cases do you get either observable args or not? The attributes in recipes are all converted for example. I find an explicit conversion clearer, but I also understand the convenience aspect.

[aplavin]

In what use cases do you get either observable args or not? The attributes in recipes are all converted for example.

I mostly have enduser code in mind, but useful for packages/function implementations as well.
This generalization is useful whenever you need to switch between regular values and observables:

• When writing plotting functions (not strictly "recipes") that accept both. Either convert everything to observables manually, or use this PR implementations. The latter is cleaner, less boilerplate, and works if some downstream paths don't take observables (this path can only be used with regular values ofc, but everything is automatic).
• When creating a plot and exploring options on the way: should it be static or interactive? Which values should be animated?

Currently, there are many cases with either completely artificial restrictions, or even error-prone:

julia> x = Observable(1)

# I guess I want to add 1 to x...
julia> y = @lift $x + 1
Observable(2)

# ... or maybe I don't
julia> y = @lift $x
ERROR

julia> x = Observable([1,2,3])
julia> y = lift(length, x)
Observable(3)

julia> x = [1,2,3]
julia> y = lift(length, x)
3-element Vector{Int64}:
 1
 1
 1

Not sure if I like enabling non-observable arguments.

No worries, preferences differ (even though I don't understand the downsides of this generalization).
Added these lift and @lift implementations to MakieExtra.jl so that anyone can use them already.

[EdsterG]

Not sure if I like enabling non-observable arguments.

IMO the behavior of lift needs to be changed to:

1. The proposed behavior in this PR
   or
2. Error on non-observable x

Both options will reduce the likelihood of error, which is the biggest problem this PR is attempting to solve.