Set default feature naming to not include feature view name. Add option to include feature view name in feature naming.

[Mwad22]

What this PR does / why we need it:
Provides a way to strip the feature_view__ prefix from feature names during retrieval and reuse feature names directly from sources. This is done by adding a feature_names_only arguments to the functions get_historical_features(), and get_online_features(). By default, we set this parameter to True, as that is what most users seem to prefer (per guidance given by @woop).

Which issue(s) this PR fixes:

Fixes #1618

Does this PR introduce a user-facing change?:

Yes, the default behaviour of calling get_historical_features() and get_online_features() now return feature names that are stripped of the feature_view__ prefix. This introduces the possibility of feature name collisions (in which case a descriptive error is thrown, informing users they can switch to the original behaviour by setting the full_feature_names=True in their retrieval function).

Added option to include feature view name as prefix in feature naming convention.
Default naming convention is now of format "feature_name", with option to name
 features in the format "featureview__feature_name" by setting the 
**full_feature_names=True** argument in get_historical_features() and get_online_features()

[woop]

Thanks for this @Mwad22!

[Mwad22]

@Mwad22 mind fixing the DCO problem?

All fixed, and I believe everything else is passing. If there's nothing else you or @tsotnet would like changed, can we ship this?I only ask because the changes touch many files so the longer we wait, the greater number of merge conflicts we'll have to resolve.

[woop]

Should this be removed?

[achals]

This has been removed in #1678

[Mwad22]

Will remove and push, must have gotten added when I rebased.

[woop]

@Mwad22 mind fixing the DCO problem?

All fixed, and I believe everything else is passing. If there's nothing else you or @tsotnet would like changed, can we ship this?I only ask because the changes touch many files so the longer we wait, the greater number of merge conflicts we'll have to resolve.

Unfortunately @tsotnet's power is offline today. I will give the PR one final scan.

[achals]

Thanks @Mwad22, this looks great to me. I had some super nitty things but happy to lgtm after they are addressed.

[feast-ci-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: achals, Mwad22

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [achals]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Mwad22]

Note, the unit tests that fail above are failing because of the following error:

An error occurred (LimitExceededException) when calling the CreateTable operation: Subscriber limit exceeded: There is a limit of 256 tables per subscriber

They are not caused by the changes in this PR.

[achals]

/lgtm

@woop and I took a look, @tsotnet's power was out today.