Fine grained config and state resources

### Motivation

This proposal is to introduce fine grained config and state resources for better access controls. For example, for a user we may want to allow them the permission to view the status of a node but do not want to allow by default access to all other state resources like load queue, list of servers or list of tasks for a worker etc. Another example, we may want to give permissions to a user to just query the datasources but not read/change any state or config of the cluster, however even for showing the datasource list on console, a read on config is required to fetch compaction status for the datasource.

### Proposed changes

The current design has the same resource name for all `STATE` and `CONFIG` resources which are _state_ and _config_ respectively. To achieve the desired results, different resource names will need to be set for these resources. For example, for `druid/coordinator/v1/config/compaction` the resource name can be _COMPACTION_ and resource type is _CONFIG_ so a `GET` on this endpoint will be a `READ on COMPACTION CONFIG` instead of `READ on CONFIG CONFIG`. Similarly appropriate names will be chosen for resources. The design always had this provision for future improvement, see [here](https://github.com/apache/druid/blob/master/server/src/main/java/org/apache/druid/server/http/security/ConfigResourceFilter.java#L38) and [here](https://github.com/apache/druid/blob/master/server/src/main/java/org/apache/druid/server/http/security/StateResourceFilter.java).

- `StateResourceFilter` and `ConfigResourceFilter` will be changed to introspect the requested url and set the resource name accordingly before performing authorization.
- Endpoints that do authorization in the method itself will be changed to set the resource names appropriately before authorizing.

### Rationale

Having fine grained access controls.

### Operational impact

If the security extension uses _state_ and _config_ as resource name for `STATE` and `CONFIG` resource types for auth checks then they would need to change the implementation to allow any name as valid and just check the resource type to preserve the old behaviour.

### Backwards Compatibility
Its backward compatible as long as exact resource name match is not done for `CONFIG` and `STATE` resource types in the security extension.

Start with server/src/main/java/org/apache/druid/server/http/security/ConfigResourceFilter.java and StateResourceFilter.java, then trace endpoints that authorize in their methods. Determine the resource names needed for the documented CONFIG and STATE endpoints and verify that authorization checks preserve the stated backward-compatibility behavior.

Written by the indexing model from the issue text.