Problem

If TokenLookup uses a source keyword that isn't recognized, CSRF silently
stops checking tokens.

The known sources are header, query, param, cookie, form. A small typo
like Header:X-CSRF-Token (capital H) or cookies:_csrf (should be cookie)
matches none of them, and there's no default case, so it's just dropped. If
every source in the lookup is like that you end up with zero extractors and no
error. CSRF then loops over an empty list, finds nothing to validate, and lets
the request through. So a typo in the config turns CSRF off without any warning.

KeyAuth already guards against this:

// middleware/key_auth.go
if len(extractors) == 0 {
    return nil, errors.New("echo key-auth middleware could not create extractors from KeyLookup string")
}

CSRF just doesn't have the same check, so this PR adds it.

For context on impact: this only happens with a misconfigured TokenLookup, and
Sec-Fetch-Site still blocks normal cross-site requests. But a security
middleware quietly doing nothing on a typo felt worth turning into an error.

Change

• CSRFConfig.ToMiddleware() now returns an error when TokenLookup produces no
  extractors (e.g. "echo csrf middleware could not create extractors from TokenLookup string"),
  matching KeyAuth. CSRFWithConfig turns that error into a startup panic.
• Added a test case.

Valid configs keep working; only a lookup where all sources are unknown is
rejected.