Move aggregations to separate internal api

What does this MR do and why?

Related to #366661 (closed)

Note: this feature is behind a disabled by default search_blobs_language_aggregation feature flag and is not currently implemented in the frontend (yet)

• Separate the aggregations call into a separate controller method (EE only)
• Add new specs
• Refactor some existing specs and shared examples
• Move language metadata under filters key

Screenshots or screen recordings

N/A

How to set up and validate locally

1. enable the feature flag: Feature.enable(:search_blobs_language_aggregation)
2. hit the new endpoint: http://gdk.test:3000/search/aggregations?scope=blobs&search=*
3. verify it comes back with json

json

[
	{
		"name": "language",
		"buckets": [
			{
				"key": {
					"language": "HTML"
				},
				"count": 18
			},
			{
				"key": {
					"language": "Ignore List"
				},
				"count": 12
			},
			{
				"key": {
					"language": "JSON"
				},
				"count": 45
			},
			{
				"key": {
					"language": "JSON with Comments"
				},
				"count": 9
			},
			{
				"key": {
					"language": "JavaScript"
				},
				"count": 537
			},
			{
				"key": {
					"language": "Makefile"
				},
				"count": 3
			},
			{
				"key": {
					"language": "Markdown"
				},
				"count": 87
			},
			{
				"key": {
					"language": "Shell"
				},
				"count": 12
			},
			{
				"key": {
					"language": "Text"
				},
				"count": 12
			},
			{
				"key": {
					"language": "YAML"
				},
				"count": 12
			}
		]
	}
]

4. try with other non-blob scopes (projects, issues, etc)
5. verify it comes back with an empty array
6. do a blobs search and verify using the performance bar that only one Elasticsearch call is made (prior to this change it would have made 2)

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.