Make `points` lazy

[dlfivefifty]

That is, return an AbstractVector.

This has the benefit that we can do fast transforms like:

x = points(Chebyshev(),100) # Returns `ChebyshevPoints`
f = Fun(exp)
f.(x)  # use transform, not evaluation by overloading `broadcast(f::Fun{<:Chebyshev}, x::ChebyshevPoints)`

While we are at it, each point should be stored in angle variables?

struct CosPoint{T} <: Real
   θ::T
end

convert(::Type{T}, x::CosPoint) = convert(T, cos(x.θ))

Then f(x::CosPoint) would no longer be numerically unstable.

[dlfivefifty]

Supporting mapped domains is a complication here. I think for that we need to resolve

https://github.com/JuliaApproximation/ApproxFun.jl/issues/133

[dlfivefifty]

Also, maybe points -> grid to avoid confusion with Point?

[dlfivefifty]

I think we just have

struct MappedGrid{MAP, GRID, T} <: AbstractVector{T}
   op::MAP
   grid::GRID
end

also, grids should have domains. Then one can do

@inline default_broadcast(f, A, Bs...) = Base.Broadcast.broadcast_c(f, containertype(A, Bs...), A, Bs...)

function broadcast(f::Fun{S}, grid::Grid{D}) where S<:Space{D} where D
  if domain(f) == domain(grid) && length(grid) ≥ ncoefficients(f)  # otherwise would need clever aliasing
    values(pad(f, length(grid)))
  else
     default_broadcast(f, grid)
  end
end

[dlfivefifty]

Probably better to support hasfasttransform(f::Fun, x::Grid)

[dlfivefifty]

This would also allow for "value-spaces" as PointSpace(ChebyshevGrid(n)), etc.