Fix history charts on views/designs never showing the continuation-to-now dash

[Salvialf]

• Views and designs (plan.js/view.js graph widgets) configured with the "Tous" (all) period never showed the dashed "continue to now" segment that indicates stale data, even when the underlying command's last value was genuinely more than a minute old.
• Root cause: cmd.ajax.php's getHistory action only resolved dateEnd to the current time for a relative date range (e.g. "7 days") or when an explicit dateEnd was provided. With dateRange=all and no explicit dates (exactly what these widgets send), dateEnd stayed unresolved, so the client received an empty value, new Date('') produced an Invalid Date in JS, and the staleness check (diffms > 60000) always evaluated to false.
• Rewrote the whole dateStart/dateEnd resolution block in getHistory, which had grown into a hard-to-follow sequence of overlapping conditions (including a latent, never-actually-reachable bug where a JSON dateRange with an end but no start key would feed the raw JSON string into DateTime::modify()).
• dateEnd is still left null for the actual history query when nothing resolves it, so history::allowFuture keeps working exactly as before (a genuinely unbounded query, not artificially capped at "now"). Only the value returned to the client for the staleness check defaults to "now" when otherwise unresolved.
• Verified against every current caller (history page, comparison mode, views, designs, mobile equivalents) with no behavior change, except one currently-unused combination (a relative dateRange combined with an explicit dateEnd but no explicit dateStart), where the computed dateStart is now relative to that explicit dateEnd instead of always relative to "now". Arguably the more correct behavior either way.