Add key to JOBSUB_POOL_MAP map that allows for desired_usage_model to be overridden

[shreyb]

@njpfnal brought up the fact that for some pools (like the DUNE global pool), our assumption that --onsite == DEDICATED,OPPORTUNISTIC doesn't hold (he believes that it's supposed to be OFFSITE for everything, but he will confirm that before we start work on this issue).

He requests that we have some sort of override. Maybe it could look something like:

$ echo $JOBSUB_POOL_MAP
{"dune":{"collector":"collector_host","onsite":"SITE_FOR_ONSITE","onsite_usage_model":"setting_for_onsite","offsite_usage_model":"setting_for_offsite}}

In the case of the DUNE global pool, if Nick's original assumption is correct, we would set, onsite_usage_model:"OFFSITE" and update the code to look for this setting.

[shreyb]

After discussing this at the jobsub project meeting on 2024-01-31, we approved this issue, but with some modifications.

1. If a user specifies --site, we should just set the desired_usage_model to DEDICATED,OPPORTUNISTIC,OFFSITE, since most GlideinWMS Frontends are configured to make sure that their glideins match ONE of the desired_usage_model. This way, whether the user requests onsite or offsite by using --site, their job will match.
2. If a user specifies --onsite, it should mimic the logic of --site=ONSITE_SITE_NAME (it would be great to call the same code pat in fact), where ONSITE_SITE_NAME gets populated from the JOBSUB_POOL_MAP or from the in-code default. desired_usage_model would get set to DEDICATED,OPPORTUNISTIC,OFFSITE like (1).
3. If a user specifies --offsite, we should set the desired_usage_model to OFFSITE.
4. Still keep the restriction where --onsite, --offsite, and --site are mutually exclusive.
5. JOBSUB_POOL_MAP should remain as is. With the changes in (1)-(4), there is no reason to modify the functionality of JOBSUB_POOL_MAP any further.