Improved feature view and model versioning

# Problem
When using Feast, it can be hard to version features with respect to models in production.
- Users modifying a re-used feature view (e.g. in response to upstream schema change) can accidentally impact other models in production
- Hard to tie versions of features together or versions of models (~`FeatureService`)

As Feast adds batch transformations or #2597, transformation logic will also need to be versioned. This is already an issue today with on demand feature views too.

# Potential solution
One way to address this is to double down on:
### 1. Feature services as the central way to retrieve features + track models.
- Registering a feature service signifies dependent features / feature views are in "production"
- Allow `feature_service.get_historical_features` or `feature_service.get_online_features`
### 2. Improvements to `feast plan` and `feast apply`
- `feast plan` that prevents deletion or editing of feature views that feature services in prod depend on (Modifying https://github.com/feast-dev/feast/blob/master/sdk/python/feast/feature_store.py#L594)
- If you remove a feature service, then the underlying feature views could be removed if no other feature service depend on it
- `feast apply` that fails in above case by default (overridable though)
- e.g. modifying the logic at https://github.com/feast-dev/feast/blob/master/sdk/python/feast/feature_store.py#L676
### 3. Feature view versioning
- Not super sure here on the best practice, but a way to say that feature view B is a new version of feature view A.