getArray and getScalar primarily make sense if the element type is a scalar (numeric or string), rather than a PropertySet or PropertyList. I don't see how getArray can return an array and getScalar can return a scalar unless the element type is a scalar. So I have made both methods raise TypeError if the element type is not a scalar.

Thus get is still a useful method and cannot be deprecated.

I also took the opportunity to remove python 2 support.

The code is acceptable as is, but I think some could be condensed, either by deprecating get() as foreseen or by reimplementing the new methods in terms of get(). Also one minor doc issue (the penalty for fixing is to have to fix further...).

I have updated the code as follows:

• Made asScalar capable of returning PropertySet and other such types. asArray still raises for those.
• _propertyContainerGet now does all the work, with a new argument enum that can be ARRAY, SCALAR or AUTO
• Deleted the asArray argument to get. The only use I found in our stack was incorrect (the argument was being treated as a default value; fixed on DM-14770). This makes the new API easier to understand because get(name, asArray=True) could handle PropertySet and such, and getArray cannot.
• Made get issue a DeprecationWarning. To do this I rewrote some existing internal code to call _propertyContainerGet so it would continue to work unchanged and without issuing a warning. I also added callGet functions to two unit tests that verify that the warning is issued; I would rather have written a context manager for this job but decided it was not worth the time to figure out how to do that. I can centralize that if desired, e.g. in a new testUtils.py module, but it's small enough I chose to duplicate the code.

Looks fine (modulo Tim's comment about the tests).