<chrono>: Need more robust handling of custom arithmetic types

[mnatsuhara]

Observed by @statementreply.

In general, we currently do not robustly handle custom arithmetic-like types. Note that we expect this use case to be very uncommon, so this is not a high-priority bug.

Until this is completely addressed, we should make sure to at least fail cleanly if custom arithmetic-like types are used. As an example, we currently use _STD nextafter on a duration::rep that could potentially be a custom arithmetic-like type, in which case it would fail cleanly.

STL/stl/inc/chrono

Lines 3243 to 3246 in 65eb507

	} else {
	const auto _Leap_sec_begin = _CHRONO ceil<_CommonType>(_Leap_sec_minus_one + seconds{1});
	_Ticks = _CommonType{_STD nextafter(_Leap_sec_begin.count(), typename _CommonType::rep{0})};
	}

[CaseyCarter]

I'm not sure there's much we can do until the Standard clarifies what the handwavy "a class emulating an arithmetic type" is supposed to mean and how the Standard Library is supposed to interact with such a thing.