Persistent Device Plugin

## Motivation

- NVIDIA’s latest DGX Spark is equipped only with unified memory hardware but not dedicated VRAM. To house such type of accelerator I suggest to introduce new “Persistent” typed device plugin.
- Unlike current level of accelerator integration, which presumes each unit of accelerator (e.g. CPU cores, host memory spaces, GPU slices) occupied exclusively to each requested kernel until termination, the persistent accelerators will be implicitly attached to kernels spawned on target [Backend.AI](http://Backend.AI) agent.
- On select NVIDIA l4t-variant devices such as DGX Spark, each GPU slice’s available memory space is determined by ongoing cgroup resource limit - which we obviously already support by intrinsic `mem` type slot - but not by GPU VRAM partition (which our current CUDA plugin’s approach stands for).
- On such circumstance, when trying to support multi-tenant usage scenarios on such device family, it would be meaningless to “slice” GPU but let the single underlying GPU available to every kernels across single node, as GPU memory space limitation will be automatically constrained with help of cgroup.
- CUDA SM partitioning feature, which is another key part of our CUDA Accelerator Plugin, would not be supported on l4t devices if we choose to go with this idea, but since we’ve observed numerous cases where GPU scheduler ignoring soft SM limit and oversubscribing in its sole discrete, so discarding the SM partitioning feature would not be a critical reason not to adapt this suggestion.

## Required Features

- Create an agent-bound interface for persistent device plugin
- Most of the interface will follow principals of existing accelerator plugin declarations but without slot management
- Modify `AbstractAgent.create_kernel()` function to notify to manager that the session is attached with the accelerator advertised by persistent device plugin

## Impact

- Proper support for DGX Spark. Yay!

## Testing Scenarios

-

JIRA Issue: BA-2845