remoteproc: add infrastructure support to allow pre-loaded remoteprocs

remoteproc: add infrastructure support to allow pre-loaded remoteprocs

The remoteproc infrastructure is enhanced to allow remoteproc drivers to
be able to connect to already loaded and/or booted remote processors. The
added infrastructure is designed to allow multiple different scenarios:
 - Support userspace driven loading, with the actual boot triggered
   through the kernel.
 - Support remote processors loaded and booted by bootloaders, with
   resource table either directly provided by the remoteproc driver or
   by remoteproc core by requesting the firmware and processing only
   the resource table.

Support for these features are provided through two new fields in the
rproc structure - 'skip_firmware_request' and 'skip_load'. These fields
are expected to be set to true as per the mode/need required by the
remoteproc drivers before a rproc_add() call. The remoteproc core skips
looking for firmware and/or loading any firmware segments using these two
state flags. The default behavior is unchanged.

The interface and implementation details for either of the above scenarios
is left to the individual remoteproc drivers. This design will be used
to achieve the following different usecases on TI SoCs:
 - Allow the TI Keystone remoteproc driver to support a userspace based
   loader. The remoteproc driver is expected to invoke rproc_boot() and
   rproc_shutdown() for triggering the boot and shutdown of the remote
   processor after the loading is completed and the resource table
   information is published to the remoteproc driver. The resource
   table is processed in-line during the rproc_boot() invocation.
 - Allow the K3 R5F remoteproc driver to be invoked in an IPC-only mode
   (No load, boot or error recovery functionality, but only establish
   IPC mechanism). The driver relies on still using the regular state
   machine flow for creating the virtio devices. The rproc .start() and
   .stop() ops are not bypassed, and the actual boot bypass is implemented
   within the driver.

Signed-off-by: Suman Anna <s-anna@ti.com>