Let callbacks resolve against something other than the controller

[NielBuys]

Two independent changes, both additive.

1. Separate the callback target from the $CI reference

CI_Form_validation::$CI was doing two unrelated jobs:

• the handle for lang, uri, router and input
• the only place a callback_ rule could be looked up

So code that wanted callbacks on anything but the controller — a model, a
service — had to overwrite $CI outright. That also handed away the core
services, and made the callback target depend on whoever assigned last.

The library is shared for the whole request and the assignment usually happens
in a constructor, so loading two such objects left the first one's callbacks
resolving to Unable to find callback validation rule. The rule never ran and
the field failed with:

Unable to access an error message corresponding to your field name X.

which reads like a missing language line, not a missing callback. That is a
long way from the cause, and it is why this took a while to find.

What changed

A separate $_callback_object, consulted only where callbacks are resolved:

$this->form_validation->set_callback_object($model)->run();
$this->form_validation->callback_object();   // read it back
$this->form_validation->set_callback_object(NULL);  // back to the CI instance

$CI is left alone, so the services keep working.

Backward compatibility

$_callback_object defaults to NULL, which means the CodeIgniter instance —
the historic behaviour. No existing caller has to change and none behaves
differently. The only touched call site is the method_exists() / invoke
pair inside _execute(), which now asks callback_object() instead of reading
$this->CI directly.

Because the library is request-scoped, the docblock tells callers to set it
immediately before run() rather than once in a constructor — otherwise
whoever constructed last owns every lookup that follows, which is the original
bug wearing a different hat.

Tests

Seven new tests in Form_validation_test, covering: the default is the CI
instance; a set object receives the callback; $CI is untouched by setting it;
NULL restores the default; a non-object is ignored; the setter is chainable;
and a genuinely missing callback still fails cleanly rather than erroring.

2. .gitattributes: check out with LF

Fifteen tests fail in a Windows clone with core.autocrlf=true and pass
everywhere else — thirteen in Form_helper_test, one in Html_helper_test,
one in Calendar_test.

They are not PHP-version failures, which is what they look like at first.
Each compares helper output against a literal multi-line string written in the
test file. The helpers build output from "\n" escapes so they always emit LF,
while the expected value picks up whatever the file on disk uses. CRLF
checkout, CRLF expectation, LF actual, failure.

.gitattributes only carried export-ignore rules, so nothing told git how to
treat line endings and core.autocrlf won by default. Now * text=auto eol=lf,
plus *.bat text eol=crlf and binary rules.

Repository content is unchanged. git add --renormalize touched no file but
.gitattributes itself, confirming the blobs were already LF and only the
checkout differed. This affects the working tree only, and PHP does not care
either way.

Verification

Full suite, PHP 8.5:

	Tests	Assertions
develop	364	1170
this branch	371	1179

All passing. The 54 PHPUnit deprecations and 33 skips are pre-existing on
develop and unchanged here.