feat(datepicker-actions): option to close on date selection or expose selectedChange on datepicker

#### Feature Description

Currently when a datepicker has a datepicker-actions component in it's content, it blocks the datepicker from closing on date selection. I'd like a way to have datepicker-actions in my datepicker component but still get the close on date selection behavior. There are 2 ways that I see of accomplishing this.

**Expose the `selectedChange` event that already exists on mat-calendar**
If the user had access to this they would easily be able to close the datepicker manually. Here's a usage example:
```html

Some static content for the user to read in the datepicker

```
It also makes sense to expose this now because before `datepicker-actions` the `datepicker` would close on selection, but now that it's held open, an app may need to do some logic on selection change and this would enable that.

**Add `closeOnSelection` input to `mat-datepicker-action`

Simply add a boolean input that allow datepicker-actions to be configured to close on selection. This one is more straightforward and probably easier for consumers to understand but not as versatile as the above solution.

#### Use Case

The most common use case would be when a consumer wants to put static content in the footer of the datepicker. Personally I am using `dateClass` to highlight dates I want to recommend for the user and want to put a key in the footer to describe what the different highlighted colors are supposed to indicate. I currently have to also add a `SELECT` and `CANCEL` button due to the way the datepicker behaves with actions, so my footer much bigger than it needs to be and the user has an extra click for each date they select.

#### Work

I've contributed before and have a pretty good idea how to implement either of the options presented above. So if the material team is interested please let me know which option would be best and I can start a PR.

Begin by tracing the interaction between mat-datepicker, mat-calendar's selectedChange event, and mat-datepicker-actions, using the two API approaches described in the issue as the entry points. Done means the maintainers' preferred behavior is implemented with a clear consumer-facing API and the datepicker still supports static footer content without requiring extra selection controls.

Written by the indexing model from the issue text.