[expr.const] Consider using "non-constant library call" more generally

Currently serveral bullets in [expr.const] are mentioning standard library components.

Constant evaluation failure required:

(5.28) an invocation of the va_arg macro ([cstdarg.syn]);
(5.29) a non-constant library call ([defns.nonconst.libcall]); or

Unspecified whether constant evaluation fails:

(5.31) an operation that has undefined behavior as specified in [library] through [thread],
(5.32) an invocation of the va_start macro ([cstdarg.syn]), or

And in [bit.pow.two]/8, constant evaluation failure is required when bit_ceil call results in UB (generally not required for library UB).

Remarks: A function call expression that violates the precondition in the Preconditions: element is not a core constant expression ([expr.const]).

It may be a consistency improvement to specify all of these cases with "non-constant library call". Although only function invocation is specified in "non-constant library call", it seems easy to extend the definition to cover function-like macros.

Compare the [expr.const] bullets (5.28), (5.29), (5.31), and (5.32) with the [bit.pow.two]/8 wording and the definition of “non-constant library call” in [defns.nonconst.libcall]. Determine whether the terminology and function-like macro coverage can be made consistent, then verify that the resulting wording preserves the intended constant-evaluation rules.