feat: new checkers http-method and http-status-code

[mmorel-35]

Splits the http-const checker into two focused checkers aligned with usestdlibvars naming conventions. No backwards compatibility required.

New checkers

• http-method — flags HTTP method string literals in all testify HTTP assertions (HTTPStatusCode, HTTPBody*, HTTPError, HTTPRedirect, HTTPSuccess)
• http-status-code — flags HTTP status code integer literals in HTTPStatusCode

// ❌ Before (both violations caught by old http-const)
assert.HTTPStatusCode(t, handler, "GET", "/", nil, 200)

// ✅ After
assert.HTTPStatusCode(t, handler, http.MethodGet, "/", nil, http.StatusOK)
//                                 ^http-method^       ^http-status-code^

Changes

• Deleted http_const.go and gen_http_const.go; replaced with http_method.go, http_status_code.go and corresponding testgen files
• Moved shared helpers (newHTTPMethodTextEdit, newHTTPStatusCodeTextEdit, httpQualifiedName) into helpers_http.go
• Updated registry, registry tests, and factory tests to reference the two new checkers
• Regenerated test data and added dedicated http-method-no-import / http-status-code-no-import test cases (auto-import fix coverage)
• Updated README table and checker documentation sections

Covers #155
Closes #141

[ccoVeille]

👍

But I would have separated http.Status* and http.Method*

I remember a discussion where @alexandear was involved in go github where people where disliking the http.Method*, but where OK for http.Status* one

Do you remember the context @alexandear ?

[alexandear]

👍

But I would have separated http.Status* and http.Method*

Do you remember the context @alexandear ?

From Brad Fitzpatrick perkeep/perkeep#1649 (comment):

I'd rather not do this change.

I added the http.Method* constants to Go but have regretted it ever since. They're worse for readers than "GET" or "POST", as the http.MethodGet and http.MethodPost share such a long http.Method prefix that they blend together.

Please use the strings instead.

As for the Status constants, those are fine, but even "200" and "404" and "500" are common enough that I don't mind them. But definitely use constants for anything that isn't 200, 404, or 500.

[mmorel-35]

Notice that the AddImports method here is reused in several other PR. This version shall be used by them as it is the most evolved version yet .

[ccoVeille]

👍

But I would have separated http.Status* and http.Method*

I remember a discussion where @alexandear was involved in go github where people where disliking the http.Method*, but where OK for http.Status* one

Do you remember the context @alexandear ?

From Brad Fitzpatrick perkeep/perkeep#1649 (comment):

I'd rather not do this change.

I added the http.Method* constants to Go but have regretted it ever since. They're worse for readers than "GET" or "POST", as the http.MethodGet and http.MethodPost share such a long http.Method prefix that they blend together.

Please use the strings instead.

As for the Status constants, those are fine, but even "200" and "404" and "500" are common enough that I don't mind them. But definitely use constants for anything that isn't 200, 404, or 500.

@mmorel-35 what are your thoughts about this

https://github.com/sashamelentyev/usestdlibvars has 2 rules for this

[mmorel-35]

I believe it's better to be aligned with what other linters are already doing so in that case, let's split this in two checkers