Rigorously handle 0d/1d interaction in factor values

Some things that would be nice:

build_design_matrices([builder], {"x": 1, "y": [1, 2, 3]})

should probably broadcast x against y -- very nice for prediction! (But if it were {"x": [1], "y": [1, 2, 3]} then that should be an error.)

build_design_matrices([builder], {"x": 1, "a": "a0"})

should not be an error. (Right now, scalar numerics get converted up to columns via atleast2d_column_default, but scalar categoricals are just an error.)

And also, that last one should perhaps return a 1d ndarray or Series, not a 2d ndarray or DataFrame. (And this also applies when the data passed in is a Series, e.g. a row from a DataFrame.) The motivation is that this would make

pred_x = build_design_matrices([builder], {"x": 1, "a": "a0"})
dot(pred_x, betas)

give you a scalar when betas.ndim == 1 or a 1d vector in the multivariate case where betas.ndim == 2. But

pred_x = build_design_matrices([builder], {"x": [1], "a": ["a0"]})
dot(pred_x, betas)

would give you a 1d vector when betas.ndim == 1 or a 2d vector in the multivariate case.

This would definitely simplify patsy's prediction code!

A concern is that just starting to return 1d design "matrices" (or Series with return_type="dataframe", oops) might break existing code.

Start with build_design_matrices and the scalar conversion path involving atleast2d_column_default. Compare the documented scalar, one-element, categorical, Series, and multivariate cases, then check the prediction code implications. Done means the requested interactions are handled consistently without overlooking the stated compatibility concern.