aerosol_physical_properties.F90: replace with CAM-SIMA I/O reader

### Issue Type

Code Clean-up

### Issue Description

During review of #504, @nusbaume originally wrote:

about this code
```fortran
! Determine the opticstype, then call the appropriate routine to read the data.
subroutine aerosol_optics_init(phys_prop, nc_id)
use cam_abortutils, only: endrun
use pio, only: pio_inq_dimid, pio_inq_dimlen
```

> Just curious as to why you are using PIO calls directly here and below, instead of, say, the File I/O object? It doesn't appear that you are doing any decomposed reads of the file data, and using the File I/O object should noticeably cut down on the number of needed lines, but maybe there is something else that I am missing?

@jimmielin wrote:
> Great question! The PIO reader in SIMA is missing a pio_inq_dimlen equivalent to query dimension lengths I think, which is needed for the physprop read. Perhaps we could add an issue to extend the PIO reader with such functionality, then we could migrate to it (this file is fully shared with CAM, so we'd have to extend PIO reader, update the sparse-checkout in CAM, then update CAM & CAM-SIMA's copy of this file)?

@nusbaume wrote:

> Thanks for the responses! Given that this is shared with CAM I don't think it is worth bringing in the File I/O object in this PR. However, long-term I would recommend replacing this with the File I/O object (and really all non-decomposed PIO reads in CAM-SIMA), for a few reasons:
>
> There are serious discussions about eventually replacing PIO entirely (as no one is around anymore to maintain it). This would be done by replacing direct PIO calls with an intermediate layer that abstracts away the details. Given that the File I/O object already does that, using it will make the switch over to a different I/O library much easier.
>
> Even though the abstract interface for the File I/O layer is defined in the CCPP-framework, the actual concrete implementation must always live on the host-side (i.e. in CAM-SIMA). So even if we abandoned the CCPP-framework entirely, we would just need to change a few lines in CAM-SIMA to have everything working again.
>
> I believe adding a dimension-getting method wouldn't be too difficult. There is also the general work around of just grabbing a variable that has the associated dimension and then just using the size or shape intrinsic functions to get the actual dimension values. So I don't think that particular missing feature would be a dealbreaker.

### Will this change answers?

Yes

### Will you be implementing this yourself?

Yes

Start with aerosol_physical_properties.F90 and trace its direct PIO dimension and data reads, then inspect the CAM-SIMA File I/O object and PIO reader interfaces. Check the shared CAM copy and sparse-checkout references mentioned in the issue. Done means the file uses the CAM-SIMA I/O reader consistently, including dimension-length handling, with both shared copies updated and the relevant read paths verified.

Written by the indexing model from the issue text.