Support the display of pending user count when modifying user cap

What does this MR do?

This MR adds the initial backend ground work to support displaying the number of pending (blocked_pending_approval) state users that will be auto-approved if an instance admin modifies the User Cap accordingly (removed or increased).

The added data attribute will only be available to the signup settings form displayed in the instance admin settings (i.e. http://localhost:3000/admin/application_settings/general -> Sign-up restrictions)

Currently this new data attribute is unused, but will be consumed in the frontend MR, here: !66654 (merged)

Refs #328237 (closed)

Database query

Query

 SELECT COUNT(*) FROM "users" WHERE ("users"."state" IN ('blocked_pending_approval')) 

Execution plan

Postgres.ai

Depesz Explain

 Aggregate  (cost=2.08..2.09 rows=1 width=8) (actual time=7.107..7.109 rows=1 loops=1)
   Buffers: shared read=3
   I/O Timings: read=7.045 write=0.000
   ->  Index Only Scan using index_users_on_state on public.users  (cost=0.43..2.08 rows=1 width=0) (actual time=7.103..7.103 rows=0 loops=1)
         Index Cond: (users.state = 'blocked_pending_approval'::text)
         Heap Fetches: 0
         Buffers: shared read=3
         I/O Timings: read=7.045 write=0.000

Time: 9.429 ms
  - planning: 2.243 ms
  - execution: 7.186 ms
    - I/O read: 7.045 ms
    - I/O write: 0.000 ms

Shared buffers:
  - hits: 0 from the buffer pool
  - reads: 3 (~24.00 KiB) from the OS file cache, including disk I/O
  - dirtied: 0
  - writes: 0

Screenshots or Screencasts (strongly suggested)

Once the frontend side is implemented, it should look like:

UX Issue

Does this MR meet the acceptance criteria?

Conformity

• I have included changelog trailers, or none are needed. (Does this MR need a changelog?)
• I have added/updated documentation, or it's not needed. (Is documentation required?)
• I have properly separated EE content from FOSS, or this MR is FOSS only. (Where should EE code go?)
• I have added information for database reviewers in the MR description, or it's not needed. (Does this MR have database related changes?)
• I have self-reviewed this MR per code review guidelines.
• This MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines)
• I have followed the style guides.
• This change is backwards compatible across updates, or this does not apply.

Availability and Testing

• I have added/updated tests following the Testing Guide, or it's not needed. (Consider all test levels. See the Test Planning Process.)
• I have tested this MR in all supported browsers, or it's not needed.
• I have informed the Infrastructure department of a default or new setting change per definition of done, or it's not needed.