Shift MHV/Health data access logic to vets-api, present access details to user on the frontend

[dcloud]

Description

Currently, MHV/health tools take a variety of approaches to determining which services a logged-in user should be able to access.

If we look at the vets-api User::Services, it appears we could use vets-api to generate a granular list of mhv/health tools a user should be able to access, and vets-website could examine the backendServices list to tell users which tools they should be able to use.

User story

As a Veteran, I want to know which tools might be available to me

Notes

• There's a lot of similar code spread across the front-end and back-end that leverage the same data points, e.g. facilities or mhv account ids, to determine access.
• Various functional aliases, e.g. vaPatient (counts a user's facilities list) and mhv_correlation_id (grabs the first identifier from the MPI list of "active mhv ids"), obscure the fact that tools are often looking at the same underlying data, and this adds complexity that creates confusion amongst engineers
• Utilizing vets-api for access checks will allow tool teams to reduce size/complexity of vets-website frontend apps

Possible tasks:

• Deprecate/remove the "functional aliases", or make the various forms
• Enhance vets-api User::Services to provide "MHV Access" and "Medical Facilities" access lists

Acceptance criteria

• QA review
• A11y review

[dcloud]

Spawned by https://github.com/department-of-veterans-affairs/va.gov-team/issues/84911

[dcloud]

Could do an MVP or proof-of-concept of User::Services like va-patient (if that is a useful alias) or mhv-id

There are about 22 (non-test, non-mock) files in vets-website that appear to use vaPatient, including an isVaPatient selector. It's not apparent that engineers would know that vaPatient is merely vets-api checking that the user's va treatment facility ids has a positive length: va_treatment_facility_ids.length.positive?