power and log simplifications return wrong results for base 1, 0 or negative

### Describe the bug

Currently, `power`/`log` rewrites check the base's nullability but not its value, so degenerate bases fold wrong.

### To Reproduce

```sql
CREATE VIEW nn AS SELECT * FROM (VALUES (1.0), (0.0), (-2.0), (2.0)) s(a);
CREATE VIEW nb AS SELECT a FROM (VALUES (1.0),(0.0),(-2.0),(2.0),(NULL)) s(a) WHERE a IS NOT NULL;
CREATE VIEW t AS SELECT * FROM (VALUES (2.0), (3.0)) s(b);

SELECT a, log(a, 1.0), log(a, a) FROM nn;
-- 0.0 and 1.0 on all four rows, a = 1.0, 0.0 and -2.0 included

SELECT a, log(a, 1.0), log(a, a) FROM nb;
-- NaN NaN / -0.0 NaN / NaN NaN / 0.0 1.0, so only the schema's nullability differs

SELECT b, power(1.0, log(1.0, b)), log(1.0, power(1.0, b)) FROM t;
-- both b; should be 1.0 and NaN

SELECT count(*) FROM t WHERE power(1.0, log(1.0, b)) = 2.0;
-- 1, should be 0

SELECT power(1.0, log(1.0, 2.0)), log(1.0, 2.0);
-- 1.0 and inf, so the all-literal form is evaluated rather than rewritten
```

### Expected behavior

What the nullable-base rows already print: `NaN` where the identity does not hold, and `1.0` for `power(1.0, log(1.0, b))`.

### Additional context

The four are `power(a, log(a,b))`, `log(a,1)`, `log(a,a)` and `log(a, power(a,b))`, each gated only on `!base_nullable`.

All four hold only for `a > 0, a != 1`.

datafusion 55.0.0

Start by reproducing the four SQL examples in the issue against DataFusion 55.0.0, then trace the power/log rewrite entry points that handle nullable bases. Compare rewritten results with the nullable-base behavior and the expected NaN, infinity, and identity results; done means all listed queries produce the expected values without regressing valid positive, non-unit bases.

Written by the indexing model from the issue text.