Bound and Unbound Symbols; bound, partially bound, and pure expressions

I'm making the case to rename `InteractiveSymbol` to `BoundSymbol`, and to remove the whole _interactive_ nomenclature throughout the codebase. `blaze.expr.expressions.Symbol` could stay as it is, or it could be renamed to `UnboundSymbol` for parallelism.

Our reasoning is as follows: we've witnessed new users tripping up with `InteractiveSymbol`s frequently, thinking wrongly that they can only be used in a REPL due to their name. Also, new users expect `Data` to be the one-stop-shop for all data-related things, when in fact, `Data` is currently made only for specific interactive usages. For instance, you can't use a `Data` object when setting up a Blaze Server--blaze server expects a `resource` instead. I see no reason why a `BoundSymbol` can't be used where a `resource` is expected -- it's just a `resource` plus a symbol.

This improvement will make `Data` return a `BoundSymbol` object, that simply associates a symbol with some resource. `Data`'s API will remain the same.

Since end-users rarely if ever create `InteractiveSymbol`s directly, we expect this to not affect existing code in a significant way.

We could keep `InteractiveSymbol` callable around, and re-implement it to raise a deprecation warning and return a `BoundSymbol` instead.

Similarly for `Symbol`: it can return an `UnboundSymbol` object. Since users _do_ use `Symbol`, this one we'd want to keep, IMO.

This paves the way conceptually towards talking about bound, partially bound, and unbound (or pure) expressions down the line.

The downside is that "bound" and "unbound" are a little jargony -- I'm open to other suggestions.

Thoughts?

Start by tracing Symbol and InteractiveSymbol in blaze.expr.expressions, then inspect Data and the resource expectations of Blaze Server. Before implementation, resolve the proposed naming and compatibility approach; done would require an agreed migration plan covering BoundSymbol, UnboundSymbol, and any deprecation behavior.

Written by the indexing model from the issue text.