Fix #635, Reduce use of uint32, add more OSAL typedefs

[jphickey]

Describe the contribution

Scrub all uses of uint32 type across OSAL, and replace most usage of this generic type with more appropriate, purpose-specific typedefs.

All use of uint32 to store an object size is now replaced with size_t.

Adds proper typedefs for:

• osal_priority_t - used for indicating a task priority
• osal_stackptr_t - for indicating a task stack pointer
• osal_index_t - for indicating a table position/array index of all internal tables
• osal_objtype_t - for indicating the type of an object

Fixes #635

Testing performed
Build and sanity test OSAL on supported platforms
Run all unit tests

Expected behavior changes
None. This is mainly a scrub of all APIs to use the proper type, but keeps it as uint32 most of the time, so it really shouldn't change anything. Except for sizes which are now size_t - so they will be 64 bits on a 64 bit platform.

System(s) tested on
Ubuntu 20.04
RTEMS 4.11

Additional context
This does expose another API problem with functions that return a size as an int32 (e.g. OS_read, OS_write, etc) .... as an int32 cannot represent the full range of possible values. We may need a type to correlate with POSIX ssize_t to address this.

Contributor Info - All information REQUIRED for consideration of pull request
Joseph Hickey, Vantage Systems, Inc.

[astrogeco]

CCB 2020-11-12 APPROVED

• this improves maintenability
• @acudmore will review
• Similar change will be done on cFE
• We'll have to think about how to do the similar fix to PSP

[jphickey]

@astrogeco - note this PR does depend on PR nasa/cFE#1003 which is currently a draft.

I can either update this draft to a final rev or we can hold off on merging this until next cycle.

[jphickey]

Note - commit 2899dfe is a rebase to current "main" branch.

One thing to consider before final merge: the osal_blockcount_t is an alias to size_t here. There were a couple entries in the OS file abstraction where these were actually uint64 values - blocks in a disk file system. In this case technically even a 32-bit CPU can have a large file system >4G. But since this is a block count - not a byte count - that means even if size_t is 32 bits, it will still be able to describe a file system of at least 2TB (for 512 byte blocks) or more depending on block size. Most filesystems seem to use a blocksize of at least 4k so that is enough for 16TB volume without overflow.

Other alternatives:

• make osal_blockcount_t to be 64 bit always.
• make a separate osal_fs_off_t (file system offset) which is 64 bits and use this in the FS layer.

(In general I prefer the simplicity of using the same type everywhere but if large filesystems on 32 bit platforms are a thing, this might not be feasible)