### Is there an existing issue for this?

- [X] I have searched the existing issues

### Feature description

LocalStack should support Server-Side-Encryption for SQS if possible, or at least pretend it does so that scripts that assume this working against AWS don't break with LocalStack.

Currently terraform for example fails when trying to create an SQS queue with `sqs_managed_sse_enabled     = true` 

### 🧑‍💻 Implementation

It would probably be fine for now to at least simulate this in a basic `CRUD` way for at least the case when using AWS managed keys for the "encryption".


Example terraform:

```hcl
provider "aws" { 
  access_key                  = "test"
  secret_key                  = "test"
  region                      = "us-east-1"
  s3_force_path_style         = true
  skip_credentials_validation = true
  skip_metadata_api_check     = true
  skip_requesting_account_id  = true

  endpoints {
    sqs            = "http://localhost:4566"
    iam            = "http://localhost:4566"
  }
}

resource "aws_sqs_queue" "sqs" {
  name                        = "myq.fifo"
  fifo_queue                  = true
  content_based_deduplication = true
  sqs_managed_sse_enabled     = true
  
  tags = {
    service     = "myq"
  }
}
```

### Anything else?

- https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-sqs-sse-queue.html
- https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-server-side-encryption.html
the queue). If you reach this limit, Amazon SQS returns the
        ``OverLimit`` error message. To avoid reaching the limit, you should
        delete messages from the queue after they're processed. You can also
        increase the number of queues you use to process your messages. To
        request a limit increase, `file a support
        request <https://console.aws.amazon.com/support/home#/case/create?issueType=service-limit-increase&limitType=service-code-sqs>`__.
        For FIFO queues, there can be a maximum of 20,000 inflight messages
        (received from a queue by a consumer, but not yet deleted from the
        queue). If you reach this limit, Amazon SQS returns no error messages.
        If you attempt to set the ``VisibilityTimeout`` to a value greater than
        the maximum time left, Amazon SQS returns an error. Amazon SQS doesn't
        automatically recalculate and increase the timeout to the maximum
        remaining time.
        Unlike with a queue, when you change the visibility timeout for a
        specific message the timeout value is applied immediately but isn't
        saved in memory for that message. If you don't delete a message after it
        is received, the visibility timeout for the message reverts to the
        original timeout value (not to the value you set using the
        ``ChangeMessageVisibility`` action) the next time the message is
        received.
        :param queue_url: The URL of the Amazon SQS queue whose message's visibility is changed.
        :param receipt_handle: The receipt handle associated with the message whose visibility timeout
        is changed.
        :param visibility_timeout: The new value for the message's visibility timeout (in seconds).
        :raises MessageNotInflight:
        :raises ReceiptHandleIsInvalid:
        """
        raise NotImplementedError
    @handler("ChangeMessageVisibilityBatch")
    def change_message_visibility_batch(