[Roadmap Feedback] vkMalloc

## Problem statement:
As encouraged by https://www.khronos.org/blog/simplifying-vulkan-one-subsystem-at-a-time I would like to add following suggestion for a future Vulkan roadmap:

Currently, Vulkan requires a whole lot of boilerplate to allocate device memory. [VMA](https://github.com/GPUOpen-LibrariesAndSDKs/VulkanMemoryAllocator) somewhat improves the situation, [but still requires a surprising amount of lines of code to acquire memory](https://github.com/GPUOpen-LibrariesAndSDKs/VulkanMemoryAllocator?tab=readme-ov-file#example). In contrast, allocating device memory in CUDA is as simple as ```cuMemAlloc(&ptr, size)```, and transfering as simple as ```cuMemcpyHtoD(target, source, numBytes)```. To my knowledge, modern GPUs all put textures, vertex buffers, storage buffers, etc. in the same physical global memory, so the need for heap-type shopping and usage flags seems obsolete, or at least not needed in the majority of cases.

What I'd love to see is a simple path that covers 99% of use cases, while making the current explicit path an opt-in, low-level improvement for power users or those that want to get stuff done first, and potentially improve things later on.

## Use Case Example(s):

Allocate device buffer and memcpy data from host to device

```
vector vertices = loadVertices(...);
uint64_t numBytes = vertices.size() * sizeof(vec3);

vk_devicePtr devicePtr;
vkMalloc(&devicePtr, numBytes);
vkMemcpyHtoD(devicePtr, vertices.data(), numBytes);
```

As with CUDA, *async counterparts to functions like memcpy could allow non-blocking, parallel data transfer from host to device.

Start by reviewing the linked Khronos roadmap post, the Vulkan Memory Allocator example, and the CUDA allocation and copy APIs described in the issue. Compare the proposed vkMalloc and vkMemcpyHtoD path with Vulkan's current explicit memory model; done would be a concrete roadmap decision or an accepted, scoped API proposal.

Written by the indexing model from the issue text.