refactor(fe): use tanstack query for client-side data fetching

[eunnbi]

Description

app/(client)/_libs
- apis
   - contestProblem.ts
   - problem.ts 
   - contest.ts
   - notice.ts
   - submission.ts
   - type.ts (공용 타입)
- queries
  - contestProblem.ts 

apis 폴더

• API 호출 함수, request params 타입 관리, response 타입 관리
• 여기저기서 선언되던 api response 타입들을 한 곳에서 관리합니다.
• API 호출 함수를 사용함으로써 따로 타입 선언을 하지 않아도 됩니다.
• 만약 백엔드 API 응답이 수정되면 한 곳에서만 타입 수정하고, 나머지 타입 에러들을 고치면 됩니다.
• 리팩토링 하면서 실제 백엔드 API 응답과 다르게 선언된 타입들을 고칠 수 있었습니다.
• 여기서 선언된 API 호출 함수들은 safeFetcher(WithAuth)를 사용해야 합니다.

queries 폴더

• query 옵션 관리
• 쿼리 키는 계층적 구조를 따릅니다. 자세한 내용은 아래 블로그를 참고해주세요~
• 참고: Query Keys를 관리하는 기준과 방법
• RegisterButton 컴포넌트 리팩토링 (useEffect -> Tanstack Query)
  1. API 호출 함수, 요청/응답 타입 추가
  2. 쿼리 옵션 추가 (앞서 추가한 API 호출 함수 사용)
  3. 쿼리 옵션과 useQuery or useSuspenseQuery 사용해 리팩토링
• 커스텀 훅으로 관리하지 않는 이유?: 커스텀 훅 내부에서 useQuery 혹은 useSuspenseQuery를 사용할지 결정해야 하는데, 이건 컴포넌트가 별도의 loading UI를 보여줘야 하냐 마냐에 따라서 결정될 수 있는 거라서 간단하게 쿼리 옵션만 관리하는 방법을 선택했습니다.
• 로컬 개발 환경에서 React Query가 내부에서 어떻게 관리하고 있는지 확인할 수 있도록 dev tool을 추가했습니다.

💡 캐시 전략을 사용하기 때문에 사용자 액션으로 인해서 (제출, 테스트) 서버 데이터가 변경되었을 때 어떤 쿼리 캐시를 무효화시킬지 파악하는 것이 중요해집니다!

Minor changes

• NextJS가 page.tsx와 layout.tsx 에 제공하는 params prop의 프로퍼티 타입들은 무조건 string 입니다!! string인데 number로 선언되어 있는 부분들이 꽤 있는 것 같은데 다 수정하진 않았어요... 잘못된 타입 선언으로 인해 쿼리 키가 일치하지 않아서 삽질했습니다... 😢 (["contest", 74, "problem", "list"] !== ["contest", "74", "problem", "list"])

Additional context

---

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines
• Read the Contributing Guidelines and follow the Commit Convention
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[eunnbi]

리뷰하다가 궁금한 거 있으면 코멘트로 달아주세요~~

[Kimhyojung0810]

LGTM🔥🔥🔥🔥

[notion-workspace]

RegisterButton 리팩토링