Revert "Disable frontend cache when implicit device sync is on."

This reverts commit 8cc6205bf7.

Reason for revert: Graphite actually reuses the bind groups between
draw calls using different pipelines and this change prevents it
from happening.

Original change's description:
> Disable frontend cache when implicit device sync is on.
>
> Normal behavior of ApiObjectBase's APIRelease() which only locks the
> device when last ref dropped is not thread safe if the object is cached
> as raw pointers by the device. Example of cached objects: bind group
> layout, pipeline, sampler, shader module.
>
> The following scenario could happen:
>  - thread A:
>     - shaderModuleA.APIRealease()
>     - shaderModuleA.refCount.Decrement() == true (ref count has reached zero)
>     - going to call shaderModuleA.LockAndDeleteThis().
>  - thread B:
>     - device.CreateShaderModule().
>     - lock()
>     - device.GetOrCreateShaderModule()
>     - shaderModuleA is in the cache, so return it.
>     - unlock()
>  - thread A:
>     - starting to call shaderModuleA.LockAndDeleteThis()
>     - lock()
>     - erase shaderModuleA from the cache.
>     - delete shaderModuleA.
>     - unlock()
>
> This CL disables caching when ImplicitDeviceSynchronization is turned on
> until we find a better solution.
>
> Bug: dawn:1769
> Change-Id: Ideb2a717ece0a40e18bd1c2bef00817262bd25da
> Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/127900
> Commit-Queue: Quyen Le <lehoangquyen@chromium.org>
> Reviewed-by: Austin Eng <enga@chromium.org>
> Kokoro: Kokoro <noreply+kokoro@google.com>

TBR=cwallez@chromium.org,enga@chromium.org,noreply+kokoro@google.com,dawn-scoped@luci-project-accounts.iam.gserviceaccount.com,lehoangquyen@chromium.org

Change-Id: Ib13bba8005402d06963865fae919388a91e718f0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: dawn:1769
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/128440
Reviewed-by: Austin Eng <enga@chromium.org>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Quyen Le <lehoangquyen@chromium.org>

docs/dawn/features/implicit_device_sync.md

@@ -1,31 +0,0 @@
-# Implicit Device Synchronization
-
-`implicit-device-sync` is an experimental feature that offers multithreading support for `dawn_native`.
-
-Additional functionality:
- - `wgpu::Device` and most of its child objects are safe to be used on multiple threads, including:
-   - `wgpu::Queue`.
-   - `wgpu::BindGroup`.
-   - `wgpu::BindGroupLayout`.
-   - `wgpu::Buffer`. See Notes.
-   - `wgpu::Texture`.
-   - `wgpu::TextureView`.
-   - `wgpu::ComputePipeline`.
-   - `wgpu::RenderPipeline`.
-   - `wgpu::PipelineLayout`.
-   - `wgpu::Sampler`.
-   - `wgpu::ShaderModule`.
-   - `wgpu::SwapChain`.
- - These objects are *not* safe to be used concurrently:
-   - `wgpu:CommandEncoder`.
-   - `wgpu:ComputePassEncoder`.
-   - `wgpu:RenderPassEncoder`.
-   - `wgpu:RenderBundleEncoder`.
-   - Except that the creation, referencing, releasing and destruction of these objects are guaranteed to be thread safe.
-
-
-Notes:
- - This feature is experimental, meaning currently it has some limitations:
-   - For `wgpu::Buffer` to be safe on multiple threads. Proper manual synchronization must be done by users to ensure that the buffer is not currently being mapped and being used by any render/compute pass encoder at the same time on different threads.
-   - Enabling this feature will disable the compatibility between `wgpu::BindGroupLayout`. That means the two different `wgpu::BindGroupLayout` objects created with equivalent `wgpu::BindGroupLayoutDescriptor` won't be considered "group-equivalent" anymore. You can only use a `wgpu::BindGroup` with a `wgpu::RenderPipeline`/`wgpu::ComputePipeline` if they are both created with the same `wgpu::BindGroupLayout`.
-     - Consider using `wgpu::RenderPipeline::GetBindGroupLayout()`/`wgpu::ComputePipeline::GetBindGroupLayout()` when creating a `wgpu::BindGroup`.